filetool.sh restores home folder directories with root permission

[GNUser]

I don't have a persistent home directory. Today I added two lines to /opt/.filetool.lst:

Code: [Select]

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:

Code: [Select]

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?

[curaga]

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.

[curaga]

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.

[Rich]

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:

Code: [Select]

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

[GNUser]

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:

Code: [Select]

$ 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:

Code: [Select]

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:

Code: [Select]

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.

[GNUser]

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.

[GNUser]

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!

[jazzbiker]

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

Code: [Select]

home/tc/somedir
and to .xfiletool.sh

Code: [Select]

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?

[GNUser]

Very cute, jazzbiker