How to maintain directory ownership when using cpio -pud /tmp/package < list ?

[bigpcman]

I noticed when I use the ( cd / ; sudo cpio -pud /tmp/package < /mnt/sda1/myfilelist.lst) command, directorys in the package directory have not maintained their original ownership. For instance:

Code: [Select]

tc@box:/tmp/package$ ls -l
drwxr-xr-x    2 tc       staff          80 Jan 26 19:14 etc/
drwxr-xr-x    3 tc       staff          60 Jan 26 18:25 home/
tc@box:/tmp/package$ cd /
tc@box:/$ ls -l
drwxr-xr-x    2 root     root         1400 Jan 26 18:07 bin/
drwxr-xr-x   10 root     root         9260 Jan 26 18:13 dev/
drwxr-xr-x    9 root     root          780 Jan 26 18:38 etc/

If I execute the command as root things get even worse, /home and tc become owned by root.

Code: [Select]

root@box:/tmp# ( cd / ; cpio -pud /tmp/package < /mnt/sda1/myfilelist.lst)
3 blocks
root@box:/tmp# cd package/
root@box:/tmp/package# ls -l
drwxr-xr-x    2 root     root           80 Jan 26 19:36 etc
drwxr-xr-x    3 root     root           60 Jan 26 19:36 home

In the first example the files in etc have the correct ownership. In the second example the files in /home/tc seem to be correct as well..

Any ideas as to how to fix this?

[vitex]

I noticed when I use the ( cd / ; sudo cpio -pud /tmp/package < /mnt/sda1/myfilelist.lst) command, directorys in the package directory have not maintained their original ownership. For instance:

Code: [Select]

tc@box:/tmp/package$ ls -l
drwxr-xr-x    2 tc       staff          80 Jan 26 19:14 etc/
drwxr-xr-x    3 tc       staff          60 Jan 26 18:25 home/
tc@box:/tmp/package$ cd /
tc@box:/$ ls -l
drwxr-xr-x    2 root     root         1400 Jan 26 18:07 bin/
drwxr-xr-x   10 root     root         9260 Jan 26 18:13 dev/
drwxr-xr-x    9 root     root          780 Jan 26 18:38 etc/


Is this really the non-sudo case?  If you are executing as user tc, you cannot create files owned by root, so you would get these ownerships.

If I execute the command as root things get even worse, /home and tc become owned by root.

Code: [Select]

root@box:/tmp# ( cd / ; cpio -pud /tmp/package < /mnt/sda1/myfilelist.lst)
3 blocks
root@box:/tmp# cd package/
root@box:/tmp/package# ls -l
drwxr-xr-x    2 root     root           80 Jan 26 19:36 etc
drwxr-xr-x    3 root     root           60 Jan 26 19:36 home

In the first example the files in etc have the correct ownership. In the second example the files in /home/tc seem to be correct as well..

Any ideas as to how to fix this?

I am not sure to which examples you are referring.  Is it the non-sudo and sudo cases or the /etc and /home cases of the second example output.

If cpio executes as a non-root user, the ownership rights are set for that user. 

If cpio executes as root, the ownership rights are copied from the original files.

Create two files owned by tc and root:

Code: [Select]

echo date >test.tc
sudo sh -c "echo date >test.root"

Execute cpio as tc:

Code: [Select]

( cd .
  { echo test.tc ; echo test.root ; } | cpio -pud /tmp/test_tc
  ls -l /tmp/test_tc
)

-rw-r--r--    1 tc       staff           5 Jan 27 02:28 test.root
-rw-r--r--    1 tc       staff           5 Jan 27 02:28 test.tc

File test.root is owned by user tc since that user cannot create files owned by root.

Execute cpio as root:

Code: [Select]

( cd .
  { echo test.tc ; echo test.root ; } | sudo cpio -pud /tmp/test_root
  ls -l /tmp/test_root
)

-rw-r--r--    1 root     staff           5 Jan 27 02:28 test.root
-rw-r--r--    1 tc       staff           5 Jan 27 02:28 test.tc

In this case test.root is owned by root and test.tc is owned by tc since root has the power to ownerships arbitrarily.

Please try your question again if this has not helped.

[bigpcman]

In the example below I have a list of files that are in /etc and /home/tc. There are a mix of files owned by root and tc. I have executed cpio as root. All the file ownership is preserved correctly.

However the directory level ownership has changed from tc for /home and /home/tc  to root.
edit: Sorry for the confusion - The permission on the /home directory is correct, the problem is the /home/tc directory changed from tc to root.

Code: [Select]

tc@box:~$ cd ..
tc@box:/home$ ls -l
drwxr-sr-x    6 tc       staff         340 Jan 27 07:01 tc/
tc@box:/home$ sudo su
root@box:~# ( cd / ; cpio -pud /tmp/package < /mnt/sda1/myfilelist.lst)
4 blocks
root@box:~# cd /tmp/package/home
root@box:/tmp/package/home# ls -l
drwxr-xr-x    2 root     root           80 Jan 27 07:02 tc
root@box:/tmp/package/home#


[Jason W]

Using passthrough mode with find will preserve the target directories' permissions.


cd /tmp/package
find . -depth -not -type d -print | sudo cpio -pumd / 2>&1 > /dev/null

[bigpcman]

Using passthrough mode with find will preserve the target directories' permissions.


cd /tmp/package
find . -depth -not -type d -print | sudo cpio -pumd / 2>&1 > /dev/null

I used "-p" passthrough mode in my example.

I'm not sure what your command does but I'm trying to create the "package container" comprised of the files in my list with full paths intact.

[vitex]

The permission on the /home directory is correct, the problem is the /home/tc directory changed from tc to root.

Thanks for the clarification. 

I tried your example with both Busybox and GNU cpio and got the same behavior, which in retrospect makes some sense to me.  If cpio is executing as root with the "-d" option to create directories and the only reference to /home/tc is to a file within that directory, then cpio knows nothing about the ownership of /home/tc and creates it with its own (root) ownership.

The simplest solution is to put "home/tc" in your file list so cpio will give /home/tc the right ownership.  ("home/tc" can go anywhere in the list, even after all of the files in /home/tc.  This is important if the file list is being generated using "find ... -depth ..." which lists directories after the files within them.)

[bigpcman]

The permission on the /home directory is correct, the problem is the /home/tc directory changed from tc to root.

Thanks for the clarification. 

I tried your example with both Busybox and GNU cpio and got the same behavior, which in retrospect makes some sense to me.  If cpio is executing as root with the "-d" option to create directories and the only reference to /home/tc is to a file within that directory, then cpio knows nothing about the ownership of /home/tc and creates it with its own (root) ownership.

The simplest solution is to put "home/tc" in your file list so cpio will give /home/tc the right ownership.  ("home/tc" can go anywhere in the list, even after all of the files in /home/tc.  This is important if the file list is being generated using "find ... -depth ..." which lists directories after the files within them.)

Thanks for your solution. I worry that this is a very easy thing to screw up by simply missing one entry or forgetting to perform this step.
Perhaps my original "tar" approach works better to eliminate the possibility of error. Using "tar" to compress files from a list and then uncompressing them to "package" seems to maintain all ownership and permissions correctly.  What do you think?

[Jason W]

A tar pipeline would also work.


tar -C //tmp/package -cvpf - . | tar -C / -xvf -

I didn't actually test for errors but that is the basic routine.

[bigpcman]

A tar pipeline would also work.


tar -C //tmp/package -cvpf - . | tar -C / -xvf -

I didn't actually test for errors but that is the basic routine.

Wow, that is quite a trick Jason. However, I don't see how it could use a list file to create the compressed archive. Anyway here are the two commands I had in mind:

Code: [Select]

tar -C / -T /mnt/sda1/myfilelist.lst -zcf /tmp/backup_name.tar.gz
tar -xf /tmp/backup_name.tar.gz -C /tmp/packagePerhaps these two commands can be arranged in a pipeline?

[vitex]

I would use rsync:

Code: [Select]

sudo rsync -av --files-from=/mnt/sda1/myfilelist.lst  /  /tmp/package

Rsync is a very valuable tool for backup-related tasks.

[Jason W]

Plain old cp -a is even simpler, and cp is in base.  It would be my preference.

cp -a /tmp/package/* /

Some preserve upstream directory perms, and others preserve existing target directory perms.  In extensions, we decided to go with preserving upstream extension directory perms to give the extension maker control over created directories. 

But on your own system, there are many ways to move files.

[vitex]

cp -a /tmp/package/* /

Bigpcman's original question was about using a list of files to specify a subset of / to copy to /tmp/package.  Your example is copying in the opposite direction.

[Jason W]

Granted, I thought the goal was to copy from /tmp/package to /.  But this would also work both ways if constructed for each:

tar -C / -T /mnt/sda1/myfilelist.lst -cpf - | (cd /tmp/package ; sudo tar xf -)


Cpio, rsync, tar pipe work with each having their own behavior of preserving perms.  Rsync preserves upstream directory perms over existing ones, tar pipe will not overwrite dir perms if the dirs themselves are not tarred.

[bmarkus]

Just curious. Do busybox and GNU tar behave on the same way?

[Jason W]

Gnu tar does not require the leading / removed from the entries in the list files.  Other than that seems the same for above command.