Hi,
S10U3: It seems, that ufs POSIX-ACLs are not properly translated to zfs
ACL4 entries, when one xfers a directory tree from UFS to ZFS.
Test case:
Assuming one has an user A and B, both belonging to group G and having
their
umask set to 022:
1) On UFS
- as user A do:
mkdir /dir
chmod 0775 /dir
setfacl -m d:u::rwx,d:g::rwx,d:o:r-x,d:m:rwx /dir
# samba would say: force create mask = 0664; directory mode = 0775
- as user B do:
cd /dir
touch x
ls -alv
- as user A do:
cd /dir
echo "bla" >x
- results in:
drwxrwxr-x+ 3 A G 512 Mar 22 01:20 .
0:user::rwx
1:group::rwx #effective:rwx
2:mask:rwx
3:other:r-x
4:default:user::rwx
5:default:group::rwx
6:default:mask:rwx
7:default:other:r-x
...
-rw-rw-r-- 1 B G 4 Mar 22 01:22 x
0:user::rw-
1:group::rw- #effective:rw-
2:mask:rw-
3:other:r--
2) On zfs
- e.g. as root do:
cp -P -r -p /dir /pool1/zfsdir
# cp: Insufficient memory to save acl entry
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
# y: Permission denied.
- result:
drwxrwxr-x+ 2 A G 4 Mar 22 01:36 .
owner@:--------------:fdi---:deny
owner@:--------------:------:deny
owner@:rwxp---A-W-Co-:fdi---:allow
owner@:-------A-W-Co-:------:allow
group@:--------------:fdi---:deny
group@:--------------:------:deny
group@:rwxp---A-W-Co-:fdi---:allow
group@:-------A-W-Co-:------:allow
everyone@:-w-p---A-W-Co-:fdi---:deny
everyone@:-------A-W-Co-:------:deny
everyone@:r-x---a-R-c--s:fdi---:allow
everyone@:------a-R-c--s:------:allow
owner@:--------------:------:deny
owner@:rwxp---A-W-Co-:------:allow
group@:--------------:------:deny
group@:rwxp----------:------:allow
everyone@:-w-p---A-W-Co-:------:deny
everyone@:r-x---a-R-c--s:------:allow
...
-rw-r--r--+ 1 B G 0 Mar 22 01:36 y
owner@:--------------:------:deny
owner@:-------A-W-Co-:------:allow
group@:--------------:------:deny
group@:-------A-W-Co-:------:allow
everyone@:-------A-W-Co-:------:deny
everyone@:------a-R-c--s:------:allow
owner@:--x-----------:------:deny
owner@:rw-p---A-W-Co-:------:allow
group@:-wxp----------:------:deny
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.
--
Otto-von-Guericke University http://www.cs.uni-magdeburg.de/
Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2
39106 Magdeburg, Germany Tel: +49 391 67 12768
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 entryI 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" >yI 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
On Thu, Mar 22, 2007 at 08:45:47AM -0600, Mark Shellenbaum wrote: Hi Mark,> Jens Elkner wrote: > > cp -P -r -p /dir /pool1/zfsdir > > # cp: Insufficient memory to save acl entry> I will open a bug on that.Also opened a case: #37814372> I can''t reproduce your simple test.Ehmm, yepp - was propably already to late :-(: s,/docs,/zfsdir,> 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.Wow, that''s a big show stopper! If I tell the users, that after the transition they have to toggle their umask before/after writing to certain directories or need to do a chmod, I''m sure they wanna hang me right on the next tree and wanna get their OS changed to Linux/Windooze... Isn''t there a flag/property for zfs, to get back the old behavior or to enable POSIX-ACLs instead of zfs-ACLs? A "force_directory_create_mode=0770,force_file_create_mode=0660'' (like for samba shares) property would be even better - no need to fight with ACLs...> >Also I haven''t found anything, which explain, how ACL4 really works on...> 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.s,yet,not yet, Ahhhh - that''s the meat I was looking for - now I''m getting a clue ;-)! Perhaps it is a good idea to include this sentence into acl(5), chmod(1), etc...> 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.OK - so ''owner@:--------------:------:deny'' has no influence at all - its just a placeholder or "empty bin" for evtl. later use. Thanx a lot!, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768
> >> 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. > > Wow, that''s a big show stopper! If I tell the users, that after the > transition they have to toggle their umask before/after writing to > certain directories or need to do a chmod, I''m sure they wanna hang me > right on the next tree and wanna get their OS changed to Linux/Windooze... >Only if your goal is to ignore a users intent on what permissions their files should be created with. Think about users who set their umask to 077. They will be upset when their files are created with a more permissive mode. The ZFS way is much more secure. What is your real desired goal? Are you just wanting anybody in a specific group to be able to read,write all files in a certain directory tree? If so, then there are other ways to achieve this, with file and directory inheritance.> Isn''t there a flag/property for zfs, to get back the old behavior > or to enable POSIX-ACLs instead of zfs-ACLs? > A "force_directory_create_mode=0770,force_file_create_mode=0660'' > (like for samba shares) property would be even better - no need to fight > with ACLs...That would be bad. That would mean that every file in a file system would be forced to be created with forced set of permissions. -Mark
On 3/22/07, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote:> > > Wow, that''s a big show stopper! If I tell the users, that after the > > transition they have to toggle their umask before/after writing to > > certain directories or need to do a chmod, I''m sure they wanna hang me > > right on the next tree and wanna get their OS changed to Linux/Windooze... > > > > Only if your goal is to ignore a users intent on what permissions their > files should be created with. Think about users who set their umask to > 077. They will be upset when their files are created with a more > permissive mode. The ZFS way is much more secure.One of the reasons for doing this is explicitly to override the user''s umask. Both up and down. Which allows users to have a strict umask while still allowing shared workspaces to function correctly. Or for them to have a generous umask while ensuring secure areas stay secure. In other words, the aim is to override any mistakes that users might make by enforcing policy using ACLs.> What is your real desired goal? Are you just wanting anybody in a > specific group to be able to read,write all files in a certain directory > tree? If so, then there are other ways to achieve this, with file and > directory inheritance.Please explain how. I''ve been trying to make this work for months with no success. The business requirement is that all files in a directory hierarchy be created mode 660 - read and write by owner and primary group. How do I do this? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
> > Please explain how. I''ve been trying to make this work for months with > no success. > > The business requirement is that all files in a directory hierarchy be > created > mode 660 - read and write by owner and primary group. How do I do > this? ># zfs set aclmode=passthrough <dataset> # mkdir dir.test # chmod A+group:<somegroup>:<desired perms>:fd:allow dir.test create files and directories under dir.test. This should allow anyone in the the desired group to read/write all files, and the passthrough of aclmode stops chmod(2) from prepending deny entries. -Mark
On 3/22/07, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote:> > > > > Please explain how. I''ve been trying to make this work for months with > > no success. > > > > The business requirement is that all files in a directory hierarchy be > > created > > mode 660 - read and write by owner and primary group. How do I do > > this? > > > > # zfs set aclmode=passthrough <dataset> > # mkdir dir.test > > # chmod A+group:<somegroup>:<desired perms>:fd:allow dir.test > > create files and directories under dir.test. > > This should allow anyone in the the desired group to read/write all > files, and the passthrough of aclmode stops chmod(2) from prepending > deny entries.This fails in a number of ways. The apparent permissions do not show group write: -rw-r--r--+ 1 ptribble sysadmin 796 Mar 22 21:11 foo Related to this, if you transfer the files somewhere else that doesn''t support these ACLs, then you lose the ACL protection and get the permission bits, which may well be incorrect. You have to specify the group. This isn''t always viable. The requirement in at least some cases is that it is the user''s primary group, and will vary between files and directories. Related to that, if you do a chgrp, the permissions don''t get reset. The ACL isn''t rewritten to change the name of the group. We need the ability for the ACL to apply to the owner and group owner of the file, not some named group. The file has an explicit ACL. That''s not what we want. We just need the permissions set according to the rules defined in various policies. This leads to a number of other issues (in addition to the copy losing information as described above). Just because it has an ACL, rcp can''t transfer it onto a non-ZFS filesystem: rcp bentley:/samba/peter/dir.test/foo . rcp: failed to set acl And foo doesn''t get transferred at all, leading to data loss. Having an ACL makes it much harder to do an audit to verify that access is correctly controlled. Another interesting issue I just noticed in trying to work around the above problems is that find -acl doesn''t give me the files - it only finds the top-level directory. This is for both zfs and ufs on S10U3 - it works fine for ufs on S10 FCS. It looks like we''re between a rock and a hard place. We want to use ZFS for one project because of snapshots and data integrity - both would give us considerable advantages over ufs (not to mention filesystem size). Unfortunately, this is critical company data and the access control has to be exactly right all the time: the default ACLs as implemented in UFS are exactly what we need and work perfectly. My next question was going to be what the best way to transfer an existing set of data to zfs while preserving the ACLs, but it would appear that isn''t even possible. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
On Thu, Mar 22, 2007 at 01:34:15PM -0600, Mark Shellenbaum wrote:> > >>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. > > > >Wow, that''s a big show stopper! If I tell the users, that after the > >transition they have to toggle their umask before/after writing to > >certain directories or need to do a chmod, I''m sure they wanna hang me > >right on the next tree and wanna get their OS changed to Linux/Windooze... > > > > Only if your goal is to ignore a users intent on what permissions their > files should be created with. Think about users who set their umask to > 077. They will be upset when their files are created with a more > permissive mode. The ZFS way is much more secure.Nope - you''re talking about a different thing. I did not say, that these ACLs would be set on every possible fs|directory on the system! We and several companies I worked for use it to have a shared data dir you might think of it as a kind of workgroup based CVS, where the members of the owning workgroup are in the role of committers. The rationale for this is obvious and actually the same as for CVS: the only thing that counts is, what one can find in /data/$workgroup/** So no need to waist time for asking, who has finally the latest version of a document or the version, which should be used wrt. communication with none-internal entities, etc. and furthermore it allows to reduce the huge pile of redundant data extremly... We used this pattern/policy successfully for more than 10 year: for window users it was achieved easily by using samba, on Linux servers using XFS ACLs and on Solaris servers using UFS ACLs. ZFS breaks it. And since Solaris has no smbmnt - we can''t even get a workaround, which makes more or less sense...> What is your real desired goal? Are you just wanting anybody in a > specific group to be able to read,write all files in a certain directory > tree? If so, then there are other ways to achieve this, with file and > directory inheritance.May be I didn''t use the right settings, but I played around with it before sending the original posting (zfs aclmode intentionally set to passthrough and added fd flags), but this didn''t work either. So a working example/demo would be helpful ...> >Isn''t there a flag/property for zfs, to get back the old behavior > >or to enable POSIX-ACLs instead of zfs-ACLs? > >A "force_directory_create_mode=0770,force_file_create_mode=0660'' > >(like for samba shares) property would be even better - no need to fight > >with ACLs... > > That would be bad. That would mean that every file in a file system > would be forced to be created with forced set of permissions.And that''s exactly the business requirement. And even more a practical expericence: Assume user always have to change their umask before writing to /data/workgroup/**. Since people are usually a little bit lazy and are focused on "get the job done", it doesn''t take very long until the have added "umask 007" to their .login/.profile whatever. But now, anybody in the same workgroup is also able to read the users private data in its $HOME, e.g. $HOME/Mail/* ... So in theory you might be right, but in practice it turns out, that you are achieving exactly the opposite... Regards, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768
> > It looks like we''re between a rock and a hard place. We want to use > ZFS for one project because of snapshots and data integrity - both > would give us considerable advantages over ufs (not to mention > filesystem size). Unfortunately, this is critical company data and the > access control has to be exactly right all the time: the default > ACLs as implemented in UFS are exactly what we need and work > perfectly. >The original plan was to allow the inheritance of owner/group/other permissions. Unfortunately, during ARC reviews we were forced to remove that functionality, due to POSIX compliance and security concerns. We can look into alternatives to provide a way to force the creation of directory trees with a specified set of permissions. -Mark
On 3/23/07, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote:> > The original plan was to allow the inheritance of owner/group/other > permissions. Unfortunately, during ARC reviews we were forced to remove > that functionality, due to POSIX compliance and security concerns.What exactly is the POSIX compliance requirement here? (It''s also not clear to me how *not* allowing control of permissions helps security in any way.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
Peter Tribble wrote:> On 3/23/07, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote: >> >> The original plan was to allow the inheritance of owner/group/other >> permissions. Unfortunately, during ARC reviews we were forced to remove >> that functionality, due to POSIX compliance and security concerns. > > What exactly is the POSIX compliance requirement here? >The ignoring of a users umask.> (It''s also not clear to me how *not* allowing control of permissions > helps security in any way.) >
>Peter Tribble wrote: >> On 3/23/07, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote: >>> >>> The original plan was to allow the inheritance of owner/group/other >>> permissions. Unfortunately, during ARC reviews we were forced to remove >>> that functionality, due to POSIX compliance and security concerns. >> >> What exactly is the POSIX compliance requirement here? >> >The ignoring of a users umask.Which is what made UFS ACLs useless until we "fixed" it to break POSIX semantics. (I think we should really have some form of uacl which, when set, forces the umask to 0 but which is used as default acl when there is no acl present) Casper
On 3/23/07, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote:> Peter Tribble wrote: > > What exactly is the POSIX compliance requirement here? > > > The ignoring of a users umask.Where in POSIX does it specify the interaction of ACLs and a user''s umask? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
Peter Tribble wrote:> On 3/23/07, Mark Shellenbaum <Mark.Shellenbaum at sun.com> wrote: >> Peter Tribble wrote: >> > What exactly is the POSIX compliance requirement here? >> > >> The ignoring of a users umask. > > Where in POSIX does it specify the interaction of ACLs and a > user''s umask? >Let me try and summarize the discussion that took place, a few years ago. The POSIX ACL draft stated: p 269: "The process umask is the user''s way of specifying security for newly created objects. It was a goal to preserve this behavior //unless it is specifically overridden in a default ACL//." However, that is a withdrawn specification and Solaris is required to conform to a set of "approved standards". The main POSIX specification doesn''t say anything specific about ACLs, but rather alternate and additional access control methods. POSIX gives clear rules for file access permissions based on umask, file mode bits, additional access control mechanisms, and alternate access control mechanisms. Most of this is discussed in section 2.3 "General Concepts". Since there is nothing in the spec that states that we *can* ignore the umask, we are therefore forced to honor it. At least until we find a way to I will open an RFE to look into alternative ways to work around this issue. -Mark