Jens Elkner wrote:
Hi,
2) On zfs
- e.g. as root do:
cp -P -r -p /dir /pool1/zfsdir
# cp: Insufficient memory to save acl entry
I will open a bug on that.
cp -r -p /dir /pool1/zfsdir
# cp: Insufficient memory to save acl entry
find dir | cpio -puvmdP /pool1/docs/
- as user B do:
cd /pool1/zfsdir/dir
touch y
- as user A do:
cd /pool1/zfsdir/dir
echo "bla" >y
I can't reproduce your simple test.
I have two user tester1 and tester2 and both are members of tstgroup
tester1$ mkdir a.dir
tester1$ chmod 775 a.dir
tester1$ setfacl -m d:u::rwx,d:g::rwx,d:o:r-x,d:m:rwx a.dir
# su - tester2
tester2$ cd a.dir
tester2$ touch b
tester2$ ls -l b
total 0
-rw-rw-r-- 1 tester2 tstgrp 0 Mar 22 08:21 b
# find a.dir -print | cpio -Pvmudp /sandbox
/sandbox/a.dir
/sandbox/a.dir/b
0 blocks
tester1$ cd /sandbox/a.dir
tester1$ touch a
# su tester2
tester2$ touch c
tester2$ ls -l
total 3
-rw-r--r--+ 1 tester1 tstgrp 0 Mar 22 08:22 a
-rw-rw-r--+ 1 tester2 tstgrp 0 Mar 22 08:21 b
-rw-r--r--+ 1 tester2 tstgrp 0 Mar 22 08:22 c
There is one big difference which you see here. ZFS always honors the
users umask, and that is why the file was created with 644 permission
rather than 664 as UFS did. ZFS has to always apply the users umask
because of POSIX.
So, has anybody a clue, how one is able to migrate directories from
ufs to zfs without loosing functionality?
I've read, that it is always possible to translate POSIX_ACLs to ACL4,
but it doesn't seem to work. So I've a big migration problem ... :(((
Also I haven't found anything, which explain, how ACL4 really works on
Solaris, i.e. how the rules are applied. Yes, in order and only "who"
matches. But what means '"who" matches', what purpose have the
'owner@:--------------:------:deny' entries, what takes precendence
(allow | deny | first match | last match), also I remember, that
sometimes I heard, that if allow once matched, everything else is
ignored - but than I' askling, why the order of the ACLEs are important.
Last but not least, what purpose have the standard perms e.g. 0644 -
completely ignored if ACLEs are present ? Or used as fallback, if no
ACLE matches or ACLE match, but have not set anywhere e.g. the r bit ?
Any hints?
Regards,
jel.
owner@ entries control the owner permissions
group@ entries control the owning group permissions
everyone@ entries control everyones permissions, not just the other
permissions.
A little example will illustrate what everyone@ does.
# chmod A=owner@:r:allow,group@:r:allow,everyone@:rwx:allow file.test
# ls -V file.test
-rwxrwxrwx 1 tester1 tstgrp 0 Mar 22 08:29 file.test
owner@:r-------------:------:allow
group@:r-------------:------:allow
everyone@:rwx-----------:------:allow
Since everyone@ is giving away rwx and there are no deny entries for
either owner@ or group@ the mode of the file becomes 777 and all users
can rwx the file.
Now if I insert a deny before the group entry the mode will change.
# chmod A1+group@:wx:deny file.test
# ls -V file.test
-rwxr--rwx 1 tester1 tstgrp 0 Mar 22 08:29 file.test
owner@:r-------------:------:allow
group@:-wx-----------:------:deny
group@:r-------------:------:allow
everyone@:rwx-----------:------:allow
Now the anyone who isn't a member of tstgroup has rwx permission to the
file.
The ACEs are processed in order and once a requested permission has been
granted a subsequent deny can't take it away, but if a permission has
yet been granted then a deny for that permission will halt the access check.
For example:
# ls -V file.test
-rw-r--r--+ 1 tester1 tstgrp 0 Mar 22 08:35 file.test
user:tester2:rwx-----------:------:allow
user:tester2:-w------------:------:deny
owner@:--x-----------:------:deny
owner@:rw-p---A-W-Co-:------:allow
group@:-wxp----------:------:deny
group@:r-------------:------:allow
everyone@:-wxp---A-W-Co-:------:deny
everyone@:r-----a-R-c--s:------:allow
In this ACL the deny entry for 'w' for tester2 has no effect, since 'w'
would have already been granted. If the first two entries had been
swapped then tester2 would be denied write permission.
A normal file that doesn't really have an ACL will have a number of deny
entries inserted into the ACL. The reason for this is to provide POSIX
compliance in that you are either in the owner class, group class or
other class. The deny entries stop the access control from proceeding
to the next entries. In the ACL shown below the deny entries on the
group@ entry will prevent a member of tstgrp from picking up write
permission from the everyone@ allow entry.
# touch file.2
# ls -V file.2
-rwxr-xrwx 1 tester1 tstgrp 0 Mar 22 08:39 file.2
owner@:--------------:------:deny
owner@:rwxp---A-W-Co-:------:allow
group@:-w-p----------:------:deny
group@:r-x-----------:------:allow
everyone@:-------A-W-Co-:------:deny
everyone@:rwxp--a-R-c--s:------:allow
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
