Dennis Clarke <dcla...@blastwave.org> wrote:
> I use star a great deal, daily in fact. I have two versions that I am
> using because one of them seems to mysteriously create ACL's when I
> perform a copy from one directory to another.
>
> The two versions that I have are :
>
> # /opt/csw/bin/star --version
> star: star 1.5 (i386-pc-solaris2.8)
> # /opt/schily/bin/star --version
> star: star 1.5a89 (i386-pc-solaris2.8)
> One of them is built by you ( 1.5 ) and the other by me ( 1.5a89 ) with
> smake and Studio 11.
In star-1.5a89 ACLs don't work if you use -find.
> Recently I had to copy a large collection of files from one dir to another
> where the source was on ZFS and the destination was an NFSv4 share. The
> end result had ACLs in it that should not be there :
>
> # ls -lap
> total 94
> drwxr-xr-x 6 16411 csw 6 Sep 29 00:51 ./
> drwxr-xr-x 22 16411 csw 38 Sep 25 10:51 ../
> drwxr-xr-x 5 16411 csw 12 Sep 29 02:32
> gcc-4.3.4-SunOS_5.10-corert/
> drwxr-xr-x 5 16411 csw 12 Sep 29 01:20
> gcc-4.3.4-SunOS_5.10-g++rt/
> drwxr-xr-x+ 5 16411 csw 19 Sep 29 03:50
> gcc-4.3.4_SunOS_5.10-pkg/
> drwxr-xr-x+ 22 root root 31 Sep 24 20:58
> gcc-4.3.4_SunOS_5.10-release/
If you like to investigate on this problem, you would need to
keep the source directory tree and send the commandline you used
for copying. In the next step we would need to investigate on the
tar archive that was created by star....
> The source dir looked like this :
>
> $ ls -ladE gcc-4.3.4_SunOS_5.10-pkg
> drwxr-xr-x 3 root root 5 2009-09-25 10:49:46.081206911
> +0000 gcc-4.3.4_SunOS_5.10-pkg
>
> The output at the other end of a copy with star looks like this :
>
> # ls -lVdE gcc-4.3.4_SunOS_5.10-pkg
> drwxr-xr-x+ 5 16411 csw 19 2009-09-29 03:50:03.038056700
> +0000 gcc-4.3.4_SunOS_5.10-pkg
> owner@:-----DaA--cC-s:------:allow
> owner@:--------------:------:deny
> group@:------a---c--s:------:allow
> group@:-----D-A---C--:------:deny
> everyone@:------a---c--s:------:allow
> everyone@:-----D-A---C--:------:deny
> owner@:--------------:------:deny
> owner@:rwxp---A-W-Co-:------:allow
> group@:-w-p----------:------:deny
> group@:r-x-----------:------:allow
> everyone@:-w-p---A-W-Co-:------:deny
> everyone@:r-x---a-R-c--s:------:allow
>
> Both the source and destination were on ZFS but the destination was a NFS
> mount on the host that performed the copy.
It may be that you are hit by a bug in Sun's NFS implementation.
Sun's tar implemantation definitely had several critical bugs in 2005 related
to ACLs. Given the fact that many critical bugreports I made for Solaris did
noit end in a fix, it may be that the related bug still exists. The bug I am
currently talking is the one that causes unpacked files to get ACLs although
the source file has no ACLs (this is independent from the unterlying file
system). The reason is that Sun tar does not _clear_ ACLs on files if the
source file has no ACLs. The destination file however may have inherited ACLs
from the dierectory. This is a serious security problem in Sun tar.
It could be that Sun's NFS implementation _creates_ ACLs when star sends a
request to _clear_ the ACLs by establishing "base ACLs" that just contain
the UNIX file permissins. From the Sun documentation, this needs to remove
existing ACLs but it may do something else if there is a bug in the NFS
implementation.
> The command was very typical :
>
> /opt/csw/bin/star -copy -p -acl -sparse -dump -C src_dir1 . dest_dir
>
> I am still baffled by the apparent ACL on a dir entry within a ZFS
> filesystem when the source never had ACLs at all.
>
> What I see is this :
>
> $ $HOME/bin/star_1.5a89 --version
> star: star 1.5a89 (i386-pc-solaris2.8)
Instead of using an old version with known bugs, you could just omit -acl
with a recent version that has no known bugs.
> /home/dclarke/bin/star_1.5a89: 0 blocks + 1593968128 bytes (total of
> 1593968128 bytes = 1556609.50k).
> /home/dclarke/bin/star_1.5a89: Total time 1735.341sec (897 kBytes/sec)
> $
>
> I should mention really poor performance also.
If you don't care about granted integrity of the copy, you could try
add -no-fsync
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
