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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
