Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: M-A-X on January 25, 2026, 08:40:40 AM
-
Installing seatd on MicroCorePure64 in persistent/copy mode works without any troubles.
However after rebooting the computer the executable program disappears from the bin directory while the tce.install script for seatd is still there.
Root cause of the problem may be related to the seatd installation script which seems to be not compatible with the copy2fs.flg
Anybody else seeing this problem?
-
Hi M-A-X
Welcome to the forum.
... Root cause of the problem may be related to the seatd installation script which seems to be not compatible with the copy2fs.flg ...
Exactly correct. The tce.install/ includes this:
# make SUID
rm -rf /usr/local/bin/seatd*
LOOP=/tmp/tcloop/seatd/usr/local/bin
cp $LOOP/seatd* /usr/local/bin
chmod a+s /usr/local/bin/seatd*
When using copy2fs.flg the extension does not get mounted to /tmp/tcloop/seatd.
As a result, the cp command copies nothing to replace the deleted files.
I think confirming the files are symbolic links prior to deleting might be prudent, maybe
something like this:
# make SUID
LOOP=/tmp/tcloop/seatd/usr/local/bin
if [ -d "$LOOP" ]
then
rm -rf /usr/local/bin/seatd*
cp $LOOP/seatd* /usr/local/bin
fi
chmod a+s /usr/local/bin/seatd*
Maybe you should PM the extension maintainer aus9 and see
what he thinks.
-
I have seen this post. The info files for labwc and weston are both ignoring my suid efforts by stating that members have to use sudo
Let me rebuild and drop all SUID and re-test for 16x and 17x.
I no plans to update 15x
-
16x early test results....not sure which desktop you are using.
I have dropped the install script entirely and info file will say something like
"If you see ..../run/seatd.sock, refusing to start....... then run $ sudo rm -rf /run/seatd.sock"
labwc and weston tested works as expected with....note I tend load lots
sudo seatd -g staff -n /run/seatd.sock & dbus-run-session labwc -s lxterminal
sudo seatd -g staff -n /run/seatd.sock & XDG_SESSION_TYPE=wayland dbus-run-session weston
woodland fails and will need a rebuild
sway....is not recognising our .profile change setting up the XDG_RUNTIME_DIR
so sway will need a rebuild as I launch sway with a ~/.local/bin/sw
Have not bothered to look at 17x until I fix and submit 16x first. Thanks for reading
-
@Rich
I think I am going to re-look at using install script after all. But have no experience at this copy2fs.flg. I could not find it as a bootcode....https://distro.ibiblio.org/tinycorelinux/faq.html#bootcodes
so if I wanted to test my updated seatd....with whatever I build...where is this flag please? The PDF section 1.9 mentions this is a copy mode...but how do I test it please?
I did find mention of copy2fs.flg under /etc/init.d/tc-config/tc-config but that appears to suggest I have
Preload drivers needed for tce/opt/home on lvm/RAID etc.......which I do not have
alternatively.....after I test it my end which is mount mode with persistent home ....I could pm M-A-X ask him to move his current seatd somewhere safe , download my updated TCE and he can decide if my changes suit?
-
@Rich
EDIT
How about I change your -d test to something like this?
Ok tested and regained woodland sway already have labwc and weston
#!/bin/sh
# make SUID
LOOP=/tmp/tcloop/seatd/usr/local/bin
[ -d "$LOOP" ] || rm -rf /usr/local/bin/seatd* && cp $LOOP/seatd* /usr/local/bin
chmod a+s /usr/local/bin/seatd*
no idea why sway and woodland misbehaved.....I will send a pm to OP shortly to test
-
tested in mount mode with persistent home on 17x....the 16x updated seatd v 0.9.2 is working as expected,
will wait now for OP to test copy 2 filesytem
-
member has blocked my attempt to send him a pm of a download link
@Rich
ok to post download link here?
its a tarball he will need to unpack etc
-
... not sure which desktop you are using ...
I am using weston on core version 16.2
... so if I wanted to test my updated seatd....with whatever I build...where is this flag please? ...
It is simply an empty file with the name "copy2fs.flg" inside your TCE directory.
-
@M-A-X
ok first rebuild a failure. second build looks ok typing on weston using seatd-launch as I need dbus stuff
How do I prove I am on copy2fs without screenshotting my Apps that shows some "installation options"
ie what command do I use please? env if interested
HOME=/home/tc
PAGER=less -EM
PS1=\u@\h:\w\$
ENV=/home/tc/.ashrc
DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-DGC1zz4k6E,guid=b554889a9be6be73003
3cfc8697749d8
BACKUP=1
COLORTERM=xterm
WAYLAND_DISPLAY=wayland-1
LOGNAME=tc
TERM=xterm
WESTON_CONFIG_FILE=
PATH=/home/tc/.local/bin:/home/tc/firefox:/usr/local/sbin:/usr/local/bin:/usr/sb
in:/usr/bin:/sbin:/bin
G_FILENAME_ENCODING=iso8859-1
XDG_RUNTIME_DIR=/run/user/1001
LANG=en_AU.UTF-8
MANPAGER=less -isR
SHELL=/bin/sh
FLWM_TITLEBAR_COLOR=58:7D:AA
PWD=/home/tc
TZ=Australia/Perth
EDITOR=vi
-
Ok I found 2 "working with less typing commands" ...I tried in my ~/.local/bin/west
last lines are
$ seatd-launch weston # (about 20 keystrokes) BUT I use a dbus session I prefer
$ seatd-launch dbus-run-session weston # (about 36 keystrokes)
and this is what I used while I am typing this. So comparing Apps method A = $ sudo -- seatd -g staff -n /run/seatd.sock & weston (about 50 keystrokes) (adding dbus-run-session > 60 keystrokes)
The first part of the explanation is this command is SUID so can drop sudo as we are temporary root, no need to mention the group staff because we are still temp root. We can drop the command to create a new seat as its a seat management system so of course it will create a seat
-
Hi aus9
... How about I change your -d test to something like this? ...
----- Snip -----
[ -d "$LOOP" ] || rm -rf /usr/local/bin/seatd* && cp $LOOP/seatd* /usr/local/bin
----- Snip -----
...
That doesn't look right. If the directory exists, you want to execute the
next 2 commands. That means it would look like this:
[ -d "$LOOP" ] && rm -rf /usr/local/bin/seatd* && cp $LOOP/seatd* /usr/local/bin
I'll demonstrate. We'll create a Loop variable, 3 file names, use ls instead of rm
and echo instead of cp:
tc@E310:~/Test$ Loop="/home/tc/.local/bin"
tc@E310:~/Test$ touch x1 x2 x3
tc@E310:~/Test$ [ -d "$Loop" ] || ls x* && echo "Copy"
Copy
tc@E310:~/Test$ It skipped the first command and only executed the second command.
Lets try it the other way:
tc@E310:~/Test$ [ -d "$Loop" ] && ls x* && echo "Copy"
x1 x2 x3
Copy
tc@E310:~/Test$ It executed both commands.
Here's another thing to watch out for when chaining commands like this.
What happens if the first command fails:
tc@E310:~/Test$ [ -d "$Loop" ] && ls y* && echo "Copy"
ls: cannot access 'y*': No such file or directory
tc@E310:~/Test$ The ls command fails so the echo command never runs.
By the way, this happens if the directory does not exist:
tc@E310:~/Test$ Loop2="/home/tc/.local/bin2"
tc@E310:~/Test$ [ -d "$Loop2" ] || ls x* && echo "Copy"
x1 x2 x3
Copy
tc@E310:~/Test$ It executes both commands, which is the opposite of what you want.
I usually take the if [ TEST ]; then Commands; fi approach because it's
harder to mess up. On occasions I do chain commands, I first create test
cases like above using harmless ls and echo commands to make sure
I got it right.
-
Hi aus9
... How do I prove I am on copy2fs without screenshotting my Apps that shows some "installation options" ...
If you:
touch /etc/sysconf/tcedir/copy2fs.flgand then reboot, the contents of all of your extensions get copied
to RAM instead of being loop mounted with links to the file system.
So it you then:
ls /tmp/tcloop/seatdyou should see:
ls: cannot access '/tmp/tcloop/seatd': No such file or directory
To restore you system to mount mode, delete /etc/sysconf/tcedir/copy2fs.flg
and reboot.
-
Is it really required to assign SUID permissions to seatd?
As we have seen this method in the seatd installation script (replacing the symlink with a regular executable file) has potential for bugs.
Furthermore it basically does not agree with the core philosophy for extensions:
=> Mount Mode = Symlinks in rootfs to the mounted TCLOOP
=> Copy Mode= Regular Files in rootfs
I believe most linux users (including me) would not mind typing "sudo seatd ..." to start the program.
-
Rich
my bad that not how I made it ....it reads
#!/bin/sh
# make SUID
SRC=/usr/local/share/seatd/files
FILE1=/usr/local/bin/seatd
FILE2=/usr/local/bin/seatd-launch
[ -f $FILE1 ] || cp $SRC/seatd /usr/local/bin
[ -f $FILE2 ] || cp $SRC/seatd-launch /usr/local/bin
chmod a+s /usr/local/bin/seatd*
-
M-A-X
Please provide evidence that seatd with SUID set reports vulnerabilities. I can find none.
But I wonder if your reasons are clear to me.
Anyone with access to the sudo command can do anything. You do understand this right?
file /usr/bin/sudo
/usr/bin/sudo: setuid executable, regular file, no read permission
ls -al /usr/bin/sudo
---s--x--x 1 root root 148148 Jan 25 00:07 /usr/bin/sudo
If I understand your fear of SUID correctly then I suggest you create a root password and add it to persistence
(2) modify your rootfs and delete sudo from it so that
(3) any root power you need needs
su
<input intended command>
If Juanito or anyone else....when I submit my updated seatd....feels I am damaging the reputation of Tinycore
I will have to accept their judgement. I have a history of spitting the dummy that Rich knows too well.
I am the original packager of seatd, and feel your questioning on my lack of security is unfair when you are using sudo so freely.
-
Hi aus9
my bad that not how I made it ....it reads ...
That looks good.
M-A-X
Please provide evidence that seatd with SUID set reports vulnerabilities. I can find none. ...
He said nothing about vulnerabilities. Read his post again:
https://forum.tinycorelinux.net/index.php/topic,27984.msg181184.html#msg181184
He mentions a potential for bugs, which did occur and is being addressed by this thread.
And he basically said typing sudo is not a burden.
-
... and feel your questioning on my lack of security is unfair when you are using sudo so freely.
My apologies, this was not my intention.
The manpage of seatd-launch gives the following statement:
seatd requires root privileges to perform its tasks. This can be achieved
through SUID of seatd-launch or by running seatd-launch as root. seatd-launch
will drop privileges from the effective user to the real user before running
the specified command. If the real user is root, this is simply a noop. You
should only run seatd-launch as root if you intend for the specified command to
run as root as well.
Now I understand why it makes sense to assign SUID permission to seatd-launch.
-
M-A-X
are you using the main repo or a mirror?
If you are using a mirror...and if my submission ....will take a while to process....lands....you could use your web browser to view the info and md5 contents
and clicking the TCE will download it
If using a member, and forgive me if you already know this but you are a new member bookmark this
http://tinycorelinux.net/16.x/x86_64/tcz/seatd.tcz.info
when that date changes....edit to strip .info and download magic should start
cheers
-
...
http://tinycorelinux.net/16.x/x86_64/tcz/seatd.tcz.info
when that date changes....edit to strip .info and download magic should start
wanted to confirm that the above quoted "when that date changes" was intended to be the word "date" as opposed to "data"
(yes, a date change would technically be a data change)
thanks
-
M-A-X
Update has landed for 16x and 17x main repos.
If it works for you, can you reply that it does....and we can then ask Rich to mark as solved.
Altho I have tested it....I am not a coder....which is why I make more mistakes than I like
but yes I lacked imagination so did not design the older version for copy2fs members
Good luck testing