Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: GNUser on September 11, 2020, 08:51:35 AM
-
I use the opt=sda3 and user=bruno boot codes. Boot process consistently changes ownership of the /mnt/sda3/opt directory to root for some reason:
$ sudo chown bruno /mnt/sda3/opt
$ ls -ld /mnt/sda3/opt
drwxrwsr-x 8 bruno staff 4096 Mar 30 02:45 /mnt/sda3/opt/
$ sudo reboot
...wait for system to reboot...
$ ls -ld /mnt/sda3/opt
drwxrwsr-x 8 root staff 4096 Mar 30 02:45 /mnt/sda3/opt/
I recursively grep'ed through /etc for both "chown" and "/opt" and did not find any clues as to how or why this happens. Any ideas?
-
Hi, GNUser!
I think, that /opt is the native part of rootfs.gz with root:staff owner, and it is filled during boot process without changing the ownership. How about this explanation?
-
Hi, jazzbiker! As always, thanks for your input.
What you're saying would explain root ownership of /opt but not the changed ownership (from bruno to root) of /mnt/sda3/opt.
To make my observation more concrete: If I shutdown TCL, boot into a different OS on same harddisk, and check the ownership of /mnt/sda3/opt, I still see that the ownership has been changed to root:staff.
-
Hi, GNUser!
Its amazing, I can say nothing yet on such behaviour :-(
Besides I've found funny trick which allows to change directory ownership during "tared" restore using -T "some.list". For example, if Your "some.list" conatins
opt
then ownership will be unchanged, but in case Your "some.list" contains
opt/../opt
ownership is updated.
I checked this trick only in the sandbox, not for full the shutdown-boot TC cycle.
According to Your refinement, sad but if You need to change ownership for some other OS use, this will not help.
-
Hi, jazzbiker. That's some funky tar behavior your discovered. Thanks for sharing :)
I found a section in /etc/init.d/tc-config that handles OPT_SETUP via the MYOPT variable. Nothing in that section seems to account for the change in ownership.
This is not a big deal, by the way. I'm just trying to understand it because I don't like unexplained behaviors.
-
Of course, its normal to understand wats going on inside Your box, I totally agree with Your intentions, thanks for asking not-obvious questions, helping to clear some hidden ways.
But as I understand Your description, the named ownership change took place not during boot, but during shutdown. Don't You quess so?
-
not during boot, but during shutdown. Don't You quess so?
Huh. I was assuming during boot but I guess it could be during shutdown. I'll do some experiments to prove which one. Stay tuned.
-
Boot process is definitely the culprit. TCL shutdown process does not change ownership of /mnt/sda3/opt:
TCL$ sudo chown bruno /mnt/sda3/opt
TCL$ ls -ld /mnt/sda3/opt
drwxrwsr-x 8 bruno staff 4096 Mar 30 02:45 /mnt/sda3/opt/
TCL$ sudo poweroff
...boot into a different OS, mount the sda3 partition, cd to the mounted sda3 partition...
Devuan$ ls -ld opt
drwxrwsr-x 8 bruno staff 4096 Mar 30 02:45 opt
-
Hmm... then the trick i'm proposing may help. If You want i will check it by myself, in order not to make the troubles for You. But I don't use any persistance, so I will do this a little bit later after some preparations, Ok?
-
Thanks, jazzbiker, but a simpler fix would be to add "sudo chown bruno /mnt/sda3/opt" to my startup jobs in ~/.X/
I'm not necessarily trying to fix the issue, just understand what's going on. If I do fix the issue, I'd like to fix it by changing the part of the boot process that's responsible for it.
-
Ok, Your way is more straightforward thus the better one, agree. If talking about understanding, I hope we'd got it :-) Thanks for Your questions, digging and contributing to finest OS ever ! :-)
-
I finally figured it out. The culprit is line 470 of /etc/init.d/tc-config, which looks like this:
yes n | cp -ai /opt/. "$MOUNTPOINT"/opt/ 2>/dev/null
The purpose of the line is to copy the files below from core.gz's /opt to user's custom /opt, but only if the files don't already exist in the latter:
.filetool.lst
bootlocal.sh
shutdown.sh
.xfiletool.lst
bootsync.sh
tcemirror
However, a side effect of the command is that it changes ownership of user's custom /opt directory. Since /opt is my only persistent directory (I don't use or want a persistent home directory), this side effect a) bothers me tremendously and b) forces me to use sudo when restoring my TCL system (which consists of just the opt, boot, and tce directories) from a network backup.
Replacing the offending line (line 470 in /etc/init.d/tc-config) with these two lines does what the command was intended to do, without the undesirable side effect:
yes n | cp -ai /opt/* "$MOUNTPOINT"/opt/ 2>/dev/null
yes n | cp -ai /opt/.[!.]* "$MOUNTPOINT"/opt/ 2>/dev/null
If possible, please include this fix in future releases.
-
Hi, GNUser!
But after copying Your persistent /opt is mounted:
mount --bind "$MOUNTPOINT"/opt/ /opt/
and in this case /opt will have bruno:staff ownership. It is not very correct for other users, lets imagine that they exist. /opt is system-wide stuff, and changing its ownership may have other side effects, which will appear later. Isn't restoring of Your persistent opt ownership better?
Never seen cp <dir>/. yet, thanks for this attraction :-)
-
in this case /opt will have bruno:staff ownership. It is not very correct for other users, lets imagine that they exist. /opt is system-wide stuff, and changing its ownership may have other side effects, which will appear later.
That's a good point, jazzbiker, which I failed to consider. Maybe this is best left alone.
Thread may be marked as Solved since now we now exactly which command changes the ownership.
-
Hi GNUser
... Thread may be marked as Solved ...
So marked.
-
I think the change is fine, added to git. Any fresh opt is still root:staff, only a customized one stays with its own ownership.
-
Hi, Core people!
Gazing over owners, permissions and dirs I was surprised by
tc@box:~$ ls -ld /
drwxr-xr-x 17 tc staff 380 Jul 4 15:55 //
Is it ok to own / not by root? Or I am doing something wrong?
-
As an exercise I've booted with "base" bootcode and
cd /
rm -r home
without sudo and any problems.
-
I think the change is fine, added to git.
Yay! :)
curaga, I realized later that we can accomplish the same result with one line instead of two, like this:
yes n | cp -ai /opt/* /opt/.[!.]* "$MOUNTPOINT"/opt/ 2>/dev/null
This is a more elegant change (more efficient, keeps line count the same). I've tested it in my remastered TCL and it works exactly as intended.
-
User tc has sudo access without a password, so access to the root dir doesn't really harm anything.