Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: GNUser on March 11, 2020, 11:07:33 AM
-
I don't have a persistent home directory. Today I added two lines to /opt/.filetool.lst:
bruno@box:~$ cat /opt/.filetool.lst
...
home/bruno/.local/share/applications/mimeapps.list
home/bruno/.X.d/startup-applications.sh
...
To my surprise, the restored directories in my home folder are owned by root:
bruno@box:~$ ls -ld ~/.X.d
drwxr-sr-x 2 root staff 60 Mar 11 10:53 /home/bruno/.X.d/
bruno@box:~$ ls -ld ~/.local
drwxr-sr-x 3 root staff 60 Mar 11 10:53 /home/bruno/.local/
This creates problems, as would be expected. Here are two obvious ones:
- I get a boot-time error saying that "Cannot /home/bruno/.local/bin: Permission denied"
- Every time I open xfe file manager it complains that "Cannot create /home/bruno/.local/share/Trash/files: Permission denied"
filetool.sh should make sure that directories restored to user's home are owned by the user, not by root.
@curaga: Do you want me to try to create a patch for filetool.sh, or do you want to look into it?
-
Please write a patch. However it may prove hard to find which dirs are new, and only changing those dirs, as others may be intentionally set to some other owner.
Alternatively, you can include dirs in filetool.lst, but that may save unwanted files.
-
https://www.gnu.org/software/tar/manual/html_node/intermediate-directories.html#SEC184
The tar manual has a page on a similar task (the tar archive has the dir, but you only requested the file's extraction). So this functionality does not exist in tar at this point, and busybox usually doesn't want incompatible additions vs upstream tools. Perhaps it's scriptable, not sure. Our case is more limited than the general case though, just sub-home dir dir ownership.
-
Hi GNUser
My automount.sh script was copied to /usr/local/sbin/ with ownership set to tc:staff. Even after backing up and restoring, it
always comes back as:
tc@E310:~$ ls -l /usr/local/sbin/automount.sh
-rwxr-xr-- 1 tc staff 7738 Nov 22 11:31 /usr/local/sbin/automount.sh
tc@E310:~$
Assuming your files ownership was set the way you intended prior to backup/restore, that would suggest something unique to /home.
Maybe take a look at setupHome in /etc/init.d/tc-functions. Years ago, prior to being fixed, it was changing ownership to tc
recursively of my entire /home directory:
http://forum.tinycorelinux.net/index.php/topic,12672.msg69074.html#msg69074
-
Thanks, Rich. For the time being I'm using a similar workaround: A startup script that changes permissions of the affected directories back to me.
I think this is a bug in BusyBox tar.
Here is proof that the directories files inside the tarball have bruno:staff permissions, which is what I want:
$ tar -tvf ./mydata.tgz
-rwxr-xr-x bruno/staff 53 2020-03-11 09:56:10 home/bruno/.local/share/applications/mimeapps.list
-rwxr-xr-x bruno/staff 396 2020-03-11 10:41:52 home/bruno/.X.d/startup-applications.sh
Now let's see what happens with the permissions when the tarball is extracted with sudo:
bruno@box:~/Downloads$ mkdir test
bruno@box:~/Downloads$ cd test
bruno@box:~/Downloads/test$ sudo tar -xvf /mnt/sda3/tce/mydata.tgz
...
bruno@box:~/Downloads/test$ ls -ld home/bruno/.X.d
drwxr-xr-x 2 root root 4096 Mar 11 15:14 home/bruno/.X.d/
As you can see, extraction with sudo tar converts ownership of the directory to root.
The behavior I'm observing is what you'd expect if I were using the -o option, which I'm not:
bruno@box:~$ tar --help
BusyBox v1.31.1 (2019-12-16 14:38:11 UTC) multi-call binary.
Usage: tar c|x|t [-ZzJjahmvokO] [-f TARFILE] [-C DIR] [-T FILE] [-X FILE] [--exclude PATTERN]... [FILE]...
Create, extract, or list files from a tar file
c Create
x Extract
t List
-f FILE Name of TARFILE ('-' for stdin/out)
-C DIR Change to DIR before operation
-v Verbose
-O Extract to stdout
-m Don't restore mtime
-o Don't restore user:group
-k Don't replace existing files
-Z (De)compress using compress
-z (De)compress using gzip
-J (De)compress using xz
-j (De)compress using bzip2
-a (De)compress using lzma
-h Follow symlinks
-T FILE File with names to include
-X FILE File with glob patterns to exclude
--exclude PATTERN Glob pattern to exclude
Oh, well. I don't want to fight what seems to be a bug in BusyBox. I thought filetool.sh was doing something unexpected, but the fault clearly lies with BusyBox tar and not with filetool.sh.
-
I just noticed that the affected directories are not inside the tarball, just the files in those directories.
The real issue is that in the process of extraction, any directories that need to be created in order to restore a file are getting slapped with root permissions.
I'm going to try deleting unwanted files from the affected directories then backup the entire directory. Hopefully if it's the actual directory that's being restored, then tar will respect the directory's ownership.
-
Hopefully if it's the actual directory that's being restored, then tar will respect the directory's ownership.
Yep, I can confirm that's the case.
Not very intuitive, but I can live with this workaround. Better than needing a complicated patch.
Cheers!
-
Hi, GNUSer!
Thank You for finding underwater stones on the shining TinyCore way )
Probably not for use, but just for fun, Your problem can be solved using existing filetool.sh infrastructure without any patches.
So if You want to backup "/home/tc/somedir/your.file" preserving directory owner and rights, You can add to .filetool.lst
home/tc/somedir
and to .xfiletool.sh
home/tc/somedir/[!y]*
home/tc/somedir/?[!o]*
home/tc/somedir/??[!u]*
home/tc/somedir/???[!r]*
home/tc/somedir/????[!.]*
home/tc/somedir/?????[!f]*
home/tc/somedir/??????[!i]*
home/tc/somedir/???????[!l]*
home/tc/somedir/????????[!e]*
Isn't it funny?
-
Very cute, jazzbiker ;D