Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: polikuo on August 28, 2023, 11:29:40 AM
-
Yes, I'm bringing this topic up again.
I just go over the Core-scripts, grepping through all the files.
It turns out, the only script that would ever care about the permission of that directory, is you guess it tce-load. :P
The directory is setup by /etc/init.d/tc-config
chgrp staff "$TCEDIR" "$TCEOPT" "$TCEINSTALLED" "$TCLOOP"
chmod g+w "$TCEDIR" "$TCEOPT" "$TCEINSTALLED" "$TCLOOP"
After that, nobody cares.
Every scripts which has that infamous directory in it only checks if a certain app has been loaded.
As for the only script who cares, tce-load can be easily patched by adding a simple "sudo".
Or if you really like the way it is, just add a few lines in tce-load to reset the "right permission".
if [ -x "$TCEINSTALLED"/$2 ]; then
if [ "$BOOTING" ] ; then
echo "$TCEINSTALLED"/$2 >> /tmp/setup.lst
else
sudo "$TCEINSTALLED"/$2
fi
else
- touch "$TCEINSTALLED"/$2
+ sudo touch "$TCEINSTALLED"/$2
fi
I'm not quite sure if everyone is OK with that, since old habit die hard.
What I'm suggesting, is to patch tce-load, then everybody can be happy.
A root:root tce.installed would be just fine, the startup scripts are run by super user anyway.
Maybe not now, but future release like TC14.1 or TC15.
I'm bringing all this up because I found a bug in submitqc.
It change the permission back and forth if run multiple times.
Spent a few minutes, found the cause, just legacy code that got left behind over the years.
I can patch it, of course, but I wanna have a definite final conclusion before I do the patching.
Do we keep this old habit for no apparent benefit ?
Or I should just fix the bug in submitqc instead of a one-liner hack to tce-load ? :P
-
I'm not sure I understand, what is the issue?
-
Simply put.
I'm packing extensions.
Got annoyed that submitqc kept reporting wrong permission with the startup script (tce.installed)
Check submitqc and found bugs, need careful examination.
Check Core-scripts and found the only script that cares is tce-load.
An easy fix to tce-load can be done without causing any trouble.
Propose to hack tce-load so we don't have to care about tce.installed permission anymore.
Not necessarily right now, perhaps for a future release.
-
Hi polikuo
... The directory is setup by /etc/init.d/tc-config
chgrp staff "$TCEDIR" "$TCEOPT" "$TCEINSTALLED" "$TCLOOP"
chmod g+w "$TCEDIR" "$TCEOPT" "$TCEINSTALLED" "$TCLOOP" ...
I believe the reason for setting group to staff is because user can vary
from install to install based on preference, but all users should belong to
the staff group. Personally, I don't feel a user should need to invoke root
privileges if they wish to manually make changes to $TCEDIR for example.
... I'm bringing all this up because I found a bug in submitqc.
It change the permission back and forth if run multiple times. ...
That's not good.
... Spent a few minutes, found the cause, just legacy code that got left behind over the years. ...
Maybe post the offending section of code to get a few more eyes on it. If it
doesn't belong, then it can be removed.
... I can patch it, of course, but I wanna have a definite final conclusion before I do the patching. ...
If it's a bug in submitqc, then that's where it should probably be fixed.
-
Why setting up the rights after untar ??
Or do tar have some options to always extract the files with very specific rights.
That can overload the archive one.
What i can see, in gnu tar you can do something like this. But this is for making the tar.
tar -c -f archive.tar --owner=0 --group=0 --no-same-owner --no-same-permissions .But i don´t know if busybox tar support that.
Why not setting the correct rights in the tar archive.
And checking the correct rights in submitqc script.
Before you can submit the extension.
-
That touch command is the only command that I have ever seen fail due to an extension jumbling up the permissions of /usr/local/tce.installed
Normally I would say adding a sudo in a script is not a good idea if we can avoid it, but there is already 13 sudo commands in tce-load. What's the harm in one more.
-
Why setting up the rights after untar ??
Actually, the command used in tce-load is
yes "$FORCE" | sudo /bin/cp -ais /tmp/tcloop/"$APPNAME"/* / 2>/dev/nullThe $FORCE variable is "n" in normal mode, thus doesn't overwrite an existing file.
If you load an app with force flag (tce-load -f -i app), the variable switch to "y".
That touch command is the only command that I have ever seen fail due to an extension jumbling up the permissions of /usr/local/tce.installed
Normally I would say adding a sudo in a script is not a good idea if we can avoid it, but there is already 13 sudo commands in tce-load. What's the harm in one more.
I totally agree with you.
What's the harm if it saves you more trouble.
-
Yes, adding sudo to the touch for the next release should be fine. But submitqc should also be fixed.
-
Hi, I'm still working on fixing submitqc
The script doesn't seem to handle the ownership of the top directory very well.
Just a few line so you could get the idea.
$ ls -l /tmp/tcloop/
drwxr-xr-x 3 tc staff 26 Aug 9 09:55 mylocale
drwxr-xr-x 3 tc staff 26 Mar 16 2014 wifi
drwxr-xr-x 4 root staff 37 May 6 23:40 wireless-6.1.25-piCore-v7
drwxr-xr-x 4 root root 37 May 1 01:44 openssl
$ busybox ls -ld /
drwxrwxr-x 17 root root 380 Jan 1 1970 /
The / is immune to changes, even if you load a file that has tc:staff at the top.
Suggestion ?
Should we care about it or should I just get rid of that from the check list ?
-
Hi polikuo,
tc@box:~$ ls -ld /
drwxr-xr-x 17 tc staff 380 Apr 12 18:43 /
tc@box:~$ uname -a
Linux box 6.1.2-tinycore #612 SMP Mon Jan 2 16:44:20 UTC 2023 i686 GNU/Linux
Where are You?
EDIT: Well, I think no matter what TC You are running, the matter is whether Your onboot.lst is empty or not. In my case it is not empty, and number of extensions are installed during tce-setup called from tc-config as root.