zfs discuss - Feb 2010 - Who is using ZFS ACL''s in production?

I''ve been surveying various forums looking for other places using ZFS
ACL''s
in production to compare notes and see how if at all they''ve handled
some
of the issues we''ve found deploying them.

So far, I haven''t found anybody using them in any substantial way, let
alone trying to leverage them to allow a very large user population to have
highly flexible control over access to their data.

Anyone here that has a non-negligible ACL deployment that would be
interested in discussing it?

Thanks...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

henson at acm.org said:
> I''ve been surveying various forums looking for other places using
ZFS ACL''s
> in production to compare notes and see how if at all they''ve
handled some of
> the issues we''ve found deploying them.
> 
> So far, I haven''t found anybody using them in any substantial way,
let alone
> trying to leverage them to allow a very large user population to have
highly
> flexible control over access to their data.
> 
> Anyone here that has a non-negligible ACL deployment that would be
interested
> in discussing it? 
We''ve been using them here for a couple of years now.  Personally,
I''d
say if you set one ACL, you''re already in "non-negligible"
territory.
It''s not easy to get them right, and usually the hardest task is in
figuring out what the users want, so we don''t use them unless the
users''
needs cannot be met using traditional Unix/POSIX permissions.

The only way we''ve been able to do this effectively is by scripting
it so it''s repeatable (and documented), and using inheritance to
propagate them to any new items which are added to shared areas.
The scripting also (sorta) covers the problem that most backup and
file transfer utilities are not capable of backing up and restoring
the NFSv4-style ACL''s on ZFS.

So, let the discussion ensue....

Regards,

Marion

On Thu, 25 Feb 2010, Marion Hakanson wrote:
> It''s not easy to get them right, and usually the hardest task is
in
> figuring out what the users want, so we don''t use them unless the
users''
> needs cannot be met using traditional Unix/POSIX permissions.
We''ve got a web GUI that hides the complexity from end users, pretty
much
they see a list of files/directories, and pick users/groups with read only
or read/write. We offer access to central user/group space via CIFS
(currently samba in s10, with an eye towards opensolaris/in-kernel server),
web, scp/sftp, kerberized NFSv4, and interactive unix login. The web server
enforces ACL''s, so users can restrict their web content by them.
We''ve had
a similar environment based on DCE/DFS for over 10 years (we''re just
about
ready to shut that down, having completed migrating everything over) and
our users have become quite acclimatized to the flexibility that this gives
them to set access control once and have it respected regardless of access
protocol.
> and using inheritance to propagate them to any new items which are added
> to shared areas.
What protocols/access methods are used to get to the underlying zfs
filesystem? The main ACL problem we''ve having now (having resolved most
of
them, yay) is interaction with chmod() and legacy mode bits, and the
disappointing ease with which an undesired chmod can completely destroy an
ACL. I finally ended up having to preload a shared library that disables
chmod() into samba, which resolved our issues for CIFS. I still haven''t
found a way to keep users'' ACL''s from being wiped by rogue
non-ACL aware
command/utilities (including, as it turns out, Solaris'' own chgrp
command).
Unfortunately, there''s currently no global way to prevent manipulation
of
legacy mode bits from destroying ACL''s. I''ve been working
around particular
instances of the problem (such as the preloaded shared library for samba,
or using "chown :<group>" rather than chgrp), but it''s
a losing battle.
There are 40 odd years of non-ACL aware stuff out there, it''s
intractable
to try and fix it all on a case by case basis. Given ZFS''s description
as
having a "pure acl" model, it really seems there should be some way to
prevent those ACL''s from getting wiped out at the drop of a chmod.
> The scripting also (sorta) covers the problem that most backup and file
> transfer utilities are not capable of backing up and restoring the
> NFSv4-style ACL''s on ZFS.
We have a central Netbackup deployment. Supposedly it supports ZFS
ACL''s,
although I''ve never actually tested that. I suppose I should at some
point
8-/.

If we can''t find some clean way to maintain ACL sanity, we might have
to
start storing ACL''s in metadata files (maintained in lockstep by our
web
control app), and having a job run around and restore broken ACL''s on
files/directories on an ongoing basis. That would be pretty kludgy :(, but
better than sensitive data suddenly becoming world readable because
somebody''s favorite editor feels the need to chmod a file after
creation to match the permissions it thinks it should have had
based on the umask. Talk about a security deficiency <sigh>.

Thanks for the info...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Thu, 25 Feb 2010, Marion Hakanson wrote:

> It''s not easy to get them right, and usually the hardest task is
in
> figuring out what the users want, so we don''t use them unless the
users''
> needs cannot be met using traditional Unix/POSIX permissions.
>    
Yeah, I''ve had nothing but horror from ACLs.  Unfortunately I
don''t seem
to be able to avoid them for CIFS with windows access.  On the other 
hand, I can''t seem to get them right, either. I''m pretty sure
the reason
VMWare refuses to run a virtual machine on my fileserver is some kind of 
ACL problem.

Standard Unix permissions are simple and clear and can easily do 
everything I''ve ever needed, and about 10 times more; ACLs are pure
pain.

First thing I''ve encountered that makes me feel like a dinosaur, and 
I''ve been in the industry 40 years.

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

Paul B. Henson wrote:
> I''ve been surveying various forums looking for other places using
ZFS ACL''s
> in production to compare notes and see how if at all they''ve
handled some
> of the issues we''ve found deploying them.
>
> So far, I haven''t found anybody using them in any substantial way,
let
> alone trying to leverage them to allow a very large user population to have
> highly flexible control over access to their data.
>
> Anyone here that has a non-negligible ACL deployment that would be
> interested in discussing it?
>
>   
One of my clients makes extensive use of ACLs.  Some of them are so 
complex, I had to write them an application to interpret and manage them!

They have a user base of around 1000, with a couple of hundred (!) 
groups.  Nearly all file access is through Samba.

-- 
Ian.

On 26/02/2010 00:56, Paul B. Henson wrote:
>
> I''ve been surveying various forums looking for other places using
ZFS ACL''s
> in production to compare notes and see how if at all they''ve
handled some
> of the issues we''ve found deploying them.
Anyone sharing files over CIFS backed by ZFS is using ACLs, particularly 
when there are only Windows clients.   There are large number and some 
very significant in size deployments.
> So far, I haven''t found anybody using them in any substantial way,
let
> alone trying to leverage them to allow a very large user population to have
> highly flexible control over access to their data.
I doubt it is something people tend to talk about or publish blogs etc 
on.   That is probably the main reason you can''t "find" them.

-- 
Darren J Moffat

On 2/25/2010 10:24 PM, Paul B. Henson wrote:
> The main ACL problem we''ve having now (having resolved most of
> them, yay) is interaction with chmod() and legacy mode bits, and the
> disappointing ease with which an undesired chmod can completely destroy an
> ACL.
examples?
Are you using aclmode=passthrough and aclinherit=passthrough?

On Fri, 26 Feb 2010, Ian Collins wrote:
> One of my clients makes extensive use of ACLs.  Some of them are so
> complex, I had to write them an application to interpret and manage them!
Yah, manipulating them directly isn''t for the faint of heart ;). But
it''s
not too hard to abstract them to a simpler interface.
> They have a user base of around 1000, with a couple of hundred (!)
> groups.  Nearly all file access is through Samba.
How did you keep Samba from whacking the ACL''s with chmod? I
couldn''t find
a configuration where some part of it didn''t chmod something at some
point.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Fri, 26 Feb 2010, Darren J Moffat wrote:
> Anyone sharing files over CIFS backed by ZFS is using ACLs, particularly
> when there are only Windows clients.  There are large number and some
> very significant in size deployments.
If you''re running the opensolaris in-kernel CIFS server, you avoid the
POSIX compatibility layer and zfs does actually work in a pure ACL fashion.
OTOH, under Solaris 10, I was unable to find a samba configuration that
didn''t result in some files being hit by a chmod and losing their ACL.
> I doubt it is something people tend to talk about or publish blogs etc
> on.  That is probably the main reason you can''t "find"
them.
It''s not like I''m typing "People who use ZFS
ACL''s" into google and nothing
pops up, I''m inquiring in various forums generally populated by Solaris
using people, in which typically a "Hey, who uses foo?" post finds a
fair
number of respondents. Given the dearth of responses, I can only conclude
their use is not very widespread. The most frequent response so far has
been along the lines of "ACL''s suck. I wish they weren''t
there" 8-/.

So far it''s been quite a struggle to deploy ACL''s on an
enterprise central
file services platform with access via multiple protocols and have them
actually be functional and reliable. I can see why the average consumer
might give up.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

I think most people are just confused by ACL''s, i know i was when i
first
started using them.  Having said that, once i got them set correctly, they
work very well for my CIFS shares.


On Fri, Feb 26, 2010 at 11:23 AM, Paul B. Henson <henson at acm.org>
wrote:
> On Fri, 26 Feb 2010, Darren J Moffat wrote:
>
> > Anyone sharing files over CIFS backed by ZFS is using ACLs,
particularly
> > when there are only Windows clients.  There are large number and some
> > very significant in size deployments.
>
> If you''re running the opensolaris in-kernel CIFS server, you avoid
the
> POSIX compatibility layer and zfs does actually work in a pure ACL fashion.
> OTOH, under Solaris 10, I was unable to find a samba configuration that
> didn''t result in some files being hit by a chmod and losing their
ACL.
>
> > I doubt it is something people tend to talk about or publish blogs etc
> > on.  That is probably the main reason you can''t
"find" them.
>
> It''s not like I''m typing "People who use ZFS
ACL''s" into google and nothing
> pops up, I''m inquiring in various forums generally populated by
Solaris
> using people, in which typically a "Hey, who uses foo?" post
finds a fair
> number of respondents. Given the dearth of responses, I can only conclude
> their use is not very widespread. The most frequent response so far has
> been along the lines of "ACL''s suck. I wish they
weren''t there" 8-/.
>
> So far it''s been quite a struggle to deploy ACL''s on an
enterprise central
> file services platform with access via multiple protocols and have them
> actually be functional and reliable. I can see why the average consumer
> might give up.
>
>
> --
> Paul B. Henson  |  (909) 979-6361  | 
http://www.csupomona.edu/~henson/<http://www.csupomona.edu/%7Ehenson/>
> Operating Systems and Network Analyst  |  henson at csupomona.edu
> California State Polytechnic University  |  Pomona CA 91768
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100226/2896e777/attachment.html>

On Fri, Feb 26, 2010 at 08:23:40AM -0800, Paul B. Henson
wrote:
> So far it''s been quite a struggle to deploy ACL''s on an
enterprise central
> file services platform with access via multiple protocols and have them
> actually be functional and reliable. I can see why the average consumer
> might give up.
Can you describe your struggles?  What could we do to make it easier to
use ACLs?  Is this about chmod [and so random apps] clobbering ACLs? or
something more fundamental about ACLs?

Nico
--

On Fri, 26 Feb 2010, Thomas Burgess wrote:
> I think most people are just confused by ACL''s, i know i was when
i first
> started using them.  Having said that, once i got them set correctly,
> they work very well for my CIFS shares.
Are you using the in-kernel CIFS server or samba? Are the files ever
accessed via NFS or local shell?


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

Did you try adding:

       nfs4: mode = special
       vfs objects = zfsacl

To the shares in smb.conf?  While we haven''t done extensive work on
S10, it appears to work well enough for our (limited) purposes (along
with setting the acl properties to passthrough on the fs).

On Fri, Feb 26, 2010 at 10:23 AM, Paul B. Henson <henson at acm.org>
wrote:
> On Fri, 26 Feb 2010, Darren J Moffat wrote:
>
>> Anyone sharing files over CIFS backed by ZFS is using ACLs,
particularly
>> when there are only Windows clients. ?There are large number and some
>> very significant in size deployments.
>
> If you''re running the opensolaris in-kernel CIFS server, you avoid
the
> POSIX compatibility layer and zfs does actually work in a pure ACL fashion.
> OTOH, under Solaris 10, I was unable to find a samba configuration that
> didn''t result in some files being hit by a chmod and losing their
ACL.
>
>> I doubt it is something people tend to talk about or publish blogs etc
>> on. ?That is probably the main reason you can''t
"find" them.
>
> It''s not like I''m typing "People who use ZFS
ACL''s" into google and nothing
> pops up, I''m inquiring in various forums generally populated by
Solaris
> using people, in which typically a "Hey, who uses foo?" post
finds a fair
> number of respondents. Given the dearth of responses, I can only conclude
> their use is not very widespread. The most frequent response so far has
> been along the lines of "ACL''s suck. I wish they
weren''t there" 8-/.
>
> So far it''s been quite a struggle to deploy ACL''s on an
enterprise central
> file services platform with access via multiple protocols and have them
> actually be functional and reliable. I can see why the average consumer
> might give up.
>
>
> --
> Paul B. Henson ?| ?(909) 979-6361 ?| ?http://www.csupomona.edu/~henson/
> Operating Systems and Network Analyst ?| ?henson at csupomona.edu
> California State Polytechnic University ?| ?Pomona CA 91768
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris.org
>

On Fri, 26 Feb 2010, Nicolas Williams wrote:
> Can you describe your struggles?  What could we do to make it easier to
> use ACLs?  Is this about chmod [and so random apps] clobbering ACLs? or
> something more fundamental about ACLs?
I understand and accept that ACL''s are complicated, and have no issues
with
that. My current struggle is that other than in a few restricted use cases,
they can not be relied on to serve their purpose, as it is far to easy for
an accidental chmod (frequently in an unexpected and unnoticed context) to
wipe them out.

Even Solaris itself is guilty of such:

	http://mail.opensolaris.org/pipermail/zfs-discuss/2010-February/037249.html

If you''re trying to use ACL''s in a general purpose deployment
involving
access by applications which are ACL-ignorant, and over NFS to other
operating systems which might not even have ACL''s themselves, I do not
believe there is any way with the current implementation to do so
successfully. Something is going to run chmod on a file or directory, and
the ACL will be broken.

I''ve already posited as to an approach that I think would make a
pure-ACL
deployment possible:

	http://mail.opensolaris.org/pipermail/zfs-discuss/2010-February/037206.html

Via this concept or something else, there needs to be a way to configure
ZFS to prevent the attempted manipulation of legacy permission mode bits
from breaking the security policy of the ACL.

If anyone has thoughts on a different approach that would achieve the same
goal, I''d love to hear about it. But I''m not sure how you
could do that as
long as the ACL is so easily mangled.

Thanks...

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Fri, 26 Feb 2010, Jason King wrote:
> Did you try adding:
>
>        nfs4: mode = special
>        vfs objects = zfsacl
>
> To the shares in smb.conf?  While we haven''t done extensive work
on
> S10, it appears to work well enough for our (limited) purposes (along
> with setting the acl properties to passthrough on the fs).
Yes, I''ve got that configuration. The ACL''s are seen and
manipulated from a
windows client fine. The problem is some samba occasionally chmod''s
stuff,
which breaks the ACL. I''m not clear on exactly the circumstances, but I
was
unable to make it stop. We disabled unix extensions, and all of the dos
attributes to mode bits mappings, but it would still screw up ACL''s as
things were copied or moved around.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On 02/26/10 10:45, Paul B. Henson wrote:
> I''ve already posited as to an approach that I think would make a
pure-ACL
> deployment possible:
>
> 
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-February/037206.html
>
> Via this concept or something else, there needs to be a way to configure
> ZFS to prevent the attempted manipulation of legacy permission mode bits
> from breaking the security policy of the ACL.
I believe this proposal is sound.

In it, you wrote:
> The feedback was that the internal Sun POSIX compliance police
> wouldn''t like that ;).
There are already per-filesystem tunables for ZFS which allow the
system to escape the confines of POSIX (noatime, for one); I don''t see
why a "chmod doesn''t truncate acls" option couldn''t
join it so long as
it was off by default and left off while conformance tests were run.

						- Bill

>>>>> "nw" == Nicolas Williams <Nicolas.Williams at
sun.com> writes:
    nw> What could we do to make it easier to use ACLs?

1. how about AFS-style ones where the effective permission is the AND
   of the ACL and the unix permission?  You might have to combine this
   with an inheritable-by-subdirectories umask setting so you could
   create ACL-dominated lands of files that are all unix 777, but this
   would stop clobbering difficult-to-recreate ACL''s as well as
   unintended information leaking.

2. define a standard API for them, add ability to replicate them to
   the GNU tools everyone else uses: GNUtar, rsync, and the fileutils
   (not the Solaris private versions full of weird options that can''t
   handle large files or long pathnames, and not the Joerg Shilling
   tool), and *GET THE CHANGES MERGED UPSTREAM* so that as other OS''s
   start supporting NFSv4, the same code is working over the ACL''s
   everywhere.

Maybe we''re beyond the point of no return for the first suggestion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100226/51894db7/attachment.bin>

On Fri, 26 Feb 2010, Bill Sommerfeld wrote:
> I believe this proposal is sound.
Mere words can not express the sheer joy with which I receive this opinion
from an @sun.com address ;).
> There are already per-filesystem tunables for ZFS which allow the system
> to escape the confines of POSIX (noatime, for one); I don''t see
why a
> "chmod doesn''t truncate acls" option couldn''t
join it so long as it was
> off by default and left off while conformance tests were run.
It always frustrates me when cutting edge technology is artificially
hampered by the chains and straitjacket of an obsolete (or at least not
necessarily relevant to the problem at hand) standard. I had the same
problem with our previous DCE/DFS environment and the POSIX mask_obj.
Compliance with standards is good, but also having the option to knowingly
disregard them is even better :).

There are (as always) various pesky details that need to be ironed out. For
example, it should probably only apply to objects with a non-trivial ACL;
ones with a trivial ACL should still be chmod''able for compatibility.

There''s also the question of what to do with the non-access-control
pieces
of the legacy mode bits that have no ACL equivilent (suid, sgid, sticky
bit, et al). I think the only way to set those is with an absolute chmod,
so there''d be no way to manipulate them in the current implementation
without whacking the ACL. That''s likely done relatively infrequently,
those
bits could always be set before the ACL is applied. In our current
deployment the only one we use is sgid on directories, which is inherited,
not directly applied.

I was hoping to find some ZFS engineers that might be interested in tossing
the concept back and forth to the point where it was workable, but so far
no luck. It looks like you work more in the network security area? Ignoring
the zfs specific details, from an abstract security perspective, it seems
generally "not good" to be able to so easily and unintentionally
subvert
explicitly configured security policy :(.

I''ve got an open case, SR#72456444, regarding chmod/ACL conflicts, if
anybody would like to help it along :).

Thanks...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Fri, February 26, 2010 12:45, Paul B. Henson wrote:
> I''ve already posited as to an approach that I think would make a
pure-ACL
> deployment possible:
>
> 
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-February/037206.html
>
> Via this concept or something else, there needs to be a way to configure
> ZFS to prevent the attempted manipulation of legacy permission mode bits
> from breaking the security policy of the ACL.
It seems to me that it should depend.

chown ddb /path/to/file
chmod 640 /path/to/file

constitutes explicit instructions to give read-write access to ddb, read
access to people in the group, and no access to others.  Now,  how should
that be combined with an ACL?

I''ll tell you, if I type that and then find I (I''m
"ddb") *can''t* read the
file, I''m going to be REALLY unhappy.  Which parts of what those
commands
say to do are "explicit" and should take precedence, and which parts
are
accidental and shouldn''t override anything?  When using the octal
number
form, I don''t think you can tell.  (If I type "chmod o-rwx",
I think I''ve
been exactly explicit about what I want, and I think I should get it if I
have permission.)

I guess it shouldn''t be unexpected that ACLs, which are clearly much
more
powerful than basic permissions, are also more complicated.  Additional
power very often arrives accompanied by more complexity.

The concept of having parts of a filesystem designated ACL-only and parts
designated permissions-only leads to a total nightmare for utilities,
applications, and admin scripts of all kinds, so I don''t think that can
be
the answer.

Maybe you could make some rules, though.  For example, off the top of my
head it seems reasonable that changes to permissions for "other"
should
not override ACL entries for specific users.  Changes to permissions for
"owner" SHOULD override ACL entries for the user that''s the
same as the
current owner, if any exist.  I''m not terribly sanguine about coming up
with a set of rules that avoids disaster and avoids surprise and is
possible to keep in your head, though.

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On Fri, Feb 26, 2010 at 02:50:05PM -0800, Paul B. Henson
wrote:
> On Fri, 26 Feb 2010, Bill Sommerfeld wrote:
> 
> > I believe this proposal is sound.
> 
> Mere words can not express the sheer joy with which I receive this opinion
> from an @sun.com address ;).
I believe we can do a bit better.

A chmod that adds (see below) or removes one of r, w or x for owner is a
simple ACL edit (the bit may turn into multiple ACE bits, but whatever)
modifying / replacing / adding owner@ ACEs (if there is one).  A similar
chmod that affecting group bits should probably apply to group@ ACEs.  A
similar chmod that affecting other should apply to any everyone@ ACEs.

For set-uid/gid and the sticky bits being set/cleared on non-directories
chmod should not affect the ACL at all.  For directories the sticky and
setgid bits may require editing the inherittable ACEs of the ACL.
> There''s also the question of what to do with the
non-access-control pieces
> of the legacy mode bits that have no ACL equivilent (suid, sgid, sticky
> bit, et al). I think the only way to set those is with an absolute chmod,
chmod(2) always takes an absolute mode.  ZFS would have to reconstruct
the relative change based on the previous mode... but how to know what
the "previous mode" was?  ZFS would have to construct one from the
owner@/group@/everyone@ + set-uid/gid + sticky bits, if any.  Best
effort will do.
> so there''d be no way to manipulate them in the current
implementation
> without whacking the ACL. That''s likely done relatively
infrequently, those
> bits could always be set before the ACL is applied. In our current
> deployment the only one we use is sgid on directories, which is inherited,
> not directly applied.
You should probably stop using the set-gid bit on directories and use
inherttable ACLs instead...

Nico
--

On Fri, Feb 26, 2010 at 05:02:34PM -0600, David Dyer-Bennet
wrote:
> 
> On Fri, February 26, 2010 12:45, Paul B. Henson wrote:
> 
> > I''ve already posited as to an approach that I think would
make a pure-ACL
> > deployment possible:
> >
> > 
http://mail.opensolaris.org/pipermail/zfs-discuss/2010-February/037206.html
> >
> > Via this concept or something else, there needs to be a way to
configure
> > ZFS to prevent the attempted manipulation of legacy permission mode
bits
> > from breaking the security policy of the ACL.
> 
> It seems to me that it should depend.
> 
> chown ddb /path/to/file
> chmod 640 /path/to/file
> 
> constitutes explicit instructions to give read-write access to ddb, read
> access to people in the group, and no access to others.  Now,  how should
> that be combined with an ACL?
The chown is irrelevant (well, it''s relevant to you in terms of your
intentions, but it''s very hard for the filesystem to consider a chmod
in
relation to earlier chowns and chgrps).

I see four ways to handle the mode mask vs. ACL conflict:

a) clobber the ACL;
b) map the change as best you can to an ACL change;
c) ignore the rwx bits in the mode mask (except on create from a POSIX
   open(2)/creat(2), in which case the ACL has to be derived from the
   initial mode);
d) fail the chmod().

All three can be surprising!  (d) may be the least surprising, but it
may disrupt some apps.  (b) is the next least surprising, but it has
some dangerous effects.  (b) is tricky because the filesystem needs to
figure out what the change actually was by tracking mode bits from the
beginning.

For (b) IMO the right thing to do would be to always track a mode mask
whose rwx bits are not actually used for authorization, but which are
used to detect changes on chmod(2), and then the changes should be
applied as best effort edits of the ACLs.  On create via non-POSIX
methods the mode mask would have to be constructed synthetically.  When
the ACL is edited the current mode bits have to be brought in sync with
owner@/group@/everyone@ ACEs.  All methods of synchronizing or
synthesizing a mode mask from/to an ACL are going to be lossy.

Nico
--

On Fri, 26 Feb 2010, Nicolas Williams wrote:
> I believe we can do a bit better.
>
> A chmod that adds (see below) or removes one of r, w or x for owner is a
> simple ACL edit (the bit may turn into multiple ACE bits, but whatever)
> modifying / replacing / adding owner@ ACEs (if there is one).  A similar
> chmod that affecting group bits should probably apply to group@ ACEs.  A
> similar chmod that affecting other should apply to any everyone@ ACEs.
I don''t necessarily think that''s better; and I believe
that''s approximately
the behavior you can already get with aclmode=passthrough.

If something is trying to change permissions on an object with a
non-trivial ACL using chmod, I think it''s safe to assume
that''s not what
the original user who configured the ACL wants. At least, that would be
safe to assume if the user had explicitly configured the hypothetical
aclmode=deny or aclmode=ignore :).

Take, for example, a problem I''m currently having on Linux clients
mounting
ZFS over NFSv4. Linux supports NFSv4, and even has a utility to manipulate
NFSv4 ACL''s that works ok (but isn''t nearly as nice as the ACL
integrated
chmod command in Solaris). However, the default behavior of the linux cp
command is to try and copy the mode bits along with the file. So, I copy
a file into zfs over the NFSv4 mount from some local location. The file is
created and inherits the explicitly configured ACL from the parent
directory; the cp command then does a chmod() on it and the ACL is broken.
That''s not what I want, I configured that inheritable ACL for a reason,
and
I want it respected regardless of the permissions of the file in its
original location.

Another instance is an application that doesn''t seem to trust creat()
and
umask to do the right thing, after creating a file it explicitly
chmod''s it
to match the permissions it thinks it should have had based on the
requested mode and the current umask. If the file inherited an explicitly
specified non-trivial ACL, there''s really nothing that can be done
about
that chmod, other than ignore or deny it, that will result in the
permissions intended by the user who configured the ACL.
> For set-uid/gid and the sticky bits being set/cleared on non-directories
> chmod should not affect the ACL at all.
Agreed.
> For directories the sticky and setgid bits may require editing the
> inherittable ACEs of the ACL.
Sticky bit yes; in fact, as it affects permissions I think I''d lump
that in
to the ignore/deny category. sgid on directory though? That doesn''t
explicitly affect permission, it just potentially changes the group
ownership of new files/directories. I suppose that indirectly affects
permissions, as the implicit group@ ACE would be applied to a different
group, but that''s probably the intention of the person setting the sgid
bit, and I don''t think any actual ACL entry changes should occur from
it.
> chmod(2) always takes an absolute mode.  ZFS would have to reconstruct
> the relative change based on the previous mode...
Or perhaps some interface extension allowing relative changes to the
non-permission mode bits? For example, chown(2) allows you to specify -1
for either the user or group, meaning don''t change that one. mode_t is
unsigned, so negative values won''t work there, but there are a ton of
extra bits in an unsigned int not relevant to the mode, perhaps setting one
of them to signify only non permission related mode bits should be
manipulated:

chmod("foo", 012000) // turn on sgid bit
chmod("foo", 010000) // turn off sgid bit
chmod("foo", 014000) // turn on suid bit
chmod("foo", 010000) // turn off suid bit
> You should probably stop using the set-gid bit on directories and use
> inherttable ACLs instead...
Hmm, I suppose that could be implemented by using an explicit group: ACE
rather than the group@ ACE, but having the group ownership of the object
match and be expressed by group@ just seems a lot cleaner. ACL''s
don''t get
rid of the concept of user and group ownership, and I don''t think
the suid/sgid concept is going to get dropped anytime soon, so might as
well avail of it :).

But back to ACL/chmod; I don''t think there''s any way to map a
permission
mode bits change via chmod to an ACL change that is guaranteed to be
acceptable to the creator of the ACL. I think there should be some form of
option available such that if an application is not ACL aware, it flat out
shouldn''t be allowed to muck with permissions on an object with a
non-trivial ACL. In such a mode, only ACL operations should be allowed to
modify the permissions. They''re really two separate security domains,
operations from one shouldn''t be mixed with the other.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Fri, Feb 26, 2010 at 04:26:43PM -0800, Paul B. Henson
wrote:
> On Fri, 26 Feb 2010, Nicolas Williams wrote:
> > I believe we can do a bit better.
> >
> > A chmod that adds (see below) or removes one of r, w or x for owner is
a
> > simple ACL edit (the bit may turn into multiple ACE bits, but
whatever)
> > modifying / replacing / adding owner@ ACEs (if there is one).  A
similar
> > chmod that affecting group bits should probably apply to group@ ACEs. 
A
> > similar chmod that affecting other should apply to any everyone@ ACEs.
> 
> I don''t necessarily think that''s better; and I believe
that''s approximately
> the behavior you can already get with aclmode=passthrough.
> 
> If something is trying to change permissions on an object with a
> non-trivial ACL using chmod, I think it''s safe to assume
that''s not what
> the original user who configured the ACL wants. At least, that would be
> safe to assume if the user had explicitly configured the hypothetical
> aclmode=deny or aclmode=ignore :).
Suppose you deny or ignore chmods.  Well, how would you ever set or
reset set-uid/gid and sticky bits?  chmod(2) deals only in absolute
modes, not relative changes, which means that in order to distinguish
those bits from the rwx bits the filesystem would have to know the
file''s current mode bits in order to compare them to the new bits --
but
this is hard (see my other e-mail in a new sub-thread).  You''d have to
remove the ACL then chmod; oof.
> Take, for example, a problem I''m currently having on Linux clients
mounting
> ZFS over NFSv4. Linux supports NFSv4, and even has a utility to manipulate
> NFSv4 ACL''s that works ok (but isn''t nearly as nice as
the ACL integrated
> chmod command in Solaris). However, the default behavior of the linux cp
> command is to try and copy the mode bits along with the file. So, I copy
> a file into zfs over the NFSv4 mount from some local location. The file is
> created and inherits the explicitly configured ACL from the parent
> directory; the cp command then does a chmod() on it and the ACL is broken.
> That''s not what I want, I configured that inheritable ACL for a
reason, and
> I want it respected regardless of the permissions of the file in its
> original location.
Can you make that utility avoid the chmod?  The mode bits should come
from the open(2)/creat(2), and there should be no need to set them again
after setting the ACL.
> Another instance is an application that doesn''t seem to trust
creat() and
> umask to do the right thing, after creating a file it explicitly
chmod''s it
> to match the permissions it thinks it should have had based on the
> requested mode and the current umask. If the file inherited an explicitly
> specified non-trivial ACL, there''s really nothing that can be done
about
> that chmod, other than ignore or deny it, that will result in the
> permissions intended by the user who configured the ACL.
Such an app is broken.
> > For set-uid/gid and the sticky bits being set/cleared on
non-directories
> > chmod should not affect the ACL at all.
> 
> Agreed.
But see above, below.
> > For directories the sticky and setgid bits may require editing the
> > inherittable ACEs of the ACL.
> 
> Sticky bit yes; in fact, as it affects permissions I think I''d
lump that in
> to the ignore/deny category. sgid on directory though? That
doesn''t
> explicitly affect permission, it just potentially changes the group
> ownership of new files/directories. I suppose that indirectly affects
> permissions, as the implicit group@ ACE would be applied to a different
> group, but that''s probably the intention of the person setting the
sgid
> bit, and I don''t think any actual ACL entry changes should occur
from it.
I think both can be implemented as inherittable ACLs.
> > chmod(2) always takes an absolute mode.  ZFS would have to reconstruct
> > the relative change based on the previous mode...
> 
> Or perhaps some interface extension allowing relative changes to the
> non-permission mode bits?
But we''d have to extend NFSv4 and get the extension adopted and
deployed.  There''s no chance of such a change being made in a short
period of time -- we''re talking years.
>                           For example, chown(2) allows you to specify -1
> for either the user or group, meaning don''t change that one.
mode_t is
> unsigned, so negative values won''t work there, but there are a ton
of
> extra bits in an unsigned int not relevant to the mode, perhaps setting one
> of them to signify only non permission related mode bits should be
> manipulated:
True, there''s enough unused bits there that you could add ignore bits
(and mode4 is an unsigned 32-bit integer in NFSv4 too), but once again
you''d have to get clients and servers to understand this...
> [...]
> 
> But back to ACL/chmod; I don''t think there''s any way to
map a permission
> mode bits change via chmod to an ACL change that is guaranteed to be
> acceptable to the creator of the ACL. I think there should be some form of
> option available such that if an application is not ACL aware, it flat out
> shouldn''t be allowed to muck with permissions on an object with a
> non-trivial ACL. In such a mode, only ACL operations should be allowed to
> modify the permissions. They''re really two separate security
domains,
> operations from one shouldn''t be mixed with the other.
But is an application that sets an ACL and chmods ACL-aware?  How can
the filesystem tell?  (Answer: it can''t really, as it may not be able
to
relate the two operations.)

As I wrote in that new sub-thread, I see no option that isn''t
surprising
in some way.  My preference would be for what I labeled as option (b).

Nico
--

On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
> chown ddb /path/to/file
> chmod 640 /path/to/file
>
> constitutes explicit instructions to give read-write access to ddb, read
> access to people in the group, and no access to others.  Now,  how should
> that be combined with an ACL?
The first changes the owner of the file, and hence what object the
special owner@ ACE applies to.

The second (assuming "file" has a non-trivial ACL) is an attempt to
change
the permission related mode bits on a file with an ACL. There are three
ways this could currently be handled by the solaris implementation, all of
which end up applying mode bit permission changes to the ACL. I''d like
to
see two more ways implemented, both of which would result in no change to
the ACL.
> I''ll tell you, if I type that and then find I (I''m
"ddb") *can''t* read the
> file, I''m going to be REALLY unhappy.
Then clearly you should configure your zfs filesystem in such a manner as
to propogate the mode bit changes to the ACL. Which is currently, and even
if the additional modes I''d like to see are implemented, would remain
the
default. So unless you explicitly selected an alternative that better met
your needs you could continue to ignore the differences between legacy mode
bits and ACL''s.
> The concept of having parts of a filesystem designated ACL-only and parts
> designated permissions-only leads to a total nightmare for utilities,
> applications, and admin scripts of all kinds, so I don''t think
that can
> be the answer.
I disagree. If your deployment scenario is better served by preventing a
ACL from being mangled by a well intentioned but destructive mapping of
legacy permission mode bits, why shouldn''t that option be available for
you? Nobody would be forced to use it. It would probably be very unwise to
set such an option on a root pool filesystem. But for a data filesystem
with files accessed both via CIFS and NFSv4, the ability to keep *exactly*
that same set of utilities, applications, and admin scripts from screwing
up your ACL''s would be invaluable.
> Maybe you could make some rules, though.
No, that''s been tried before. There is no good mapping from mode bits
to
ACL''s. My understanding is that Sun is currently considering getting
rid of
both the groupmask and passthrough aclmode''s (both examples of trying
to
apply rules to map mode bit changes to ACL''s), leaving only discard. I
actually agree with that -- if you''re going to apply mode bit changes
to an
object with an ACL, you might as well just get rid of it. However, in
addition to discard, I think an option to just not *let* the ACL be
destroyed should also be available.

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Fri, 26 Feb 2010, Nicolas Williams wrote:
> a) clobber the ACL;
> b) map the change as best you can to an ACL change;
> c) ignore the rwx bits in the mode mask (except on create from a POSIX
>    open(2)/creat(2), in which case the ACL has to be derived from the
>    initial mode);
> d) fail the chmod().
Option d I believe maps to my proposed aclmode=deny; option c I *think*
lines up with my aclmode=discard, and even takes care of the issue of
flipping the suid/sgid et al bits, as an absolute chmod of 0200 would turn
on sgid and the ugo parts would be ignored (and the ACL would only need to
be derived if the three special ACE''s aren''t specified by
inheritance
(which they probably would be if somebody configured option c)).

a and b are both currently available, what do I need to do to get you on
board with implementing c and d ;)?
> All three can be surprising!
Agreed. There is no one, two, three, or even four different ways of
handling this issue that will meet the needs of every possible deployment.
But without getting into ridiculous levels of complexity, having some
reasonable number of options available seems highly desirable.

Evil thought -- implement a way to attach a custom chmod->ACL mapper to a
zfs filesystem allowing some basic scripting language to specify what
happens. Then everybody could make it do exactly what they want :).


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Fri, 26 Feb 2010, Nicolas Williams wrote:
> Suppose you deny or ignore chmods.  Well, how would you ever set or reset
> set-uid/gid and sticky bits?  chmod(2) deals only in absolute modes, not
> relative changes, which means that in order to distinguish those bits
> from the rwx bits the filesystem would have to know the file''s
current
> mode bits in order to compare them to the new bits -- but this is hard
> (see my other e-mail in a new sub-thread).  You''d have to remove
the ACL
> then chmod; oof.
You actually answered that in your previous email with option c. Ignore the
ugo bits of the argument to chmod, and only process the suid/sgid/sticky
bits. The filesystem does know the current mode bits when chmod is called,
doesn''t it?

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/sys/zfs_znode.h

line 145, the zp_mode value in the znode_phys_t structure, labeled "file
mode bits". At any given time, unless I''m mistaken, this value
stores the
legacy mode bits for an object, distinct from and separate of the ACL.

It seems it would be fairly trivial to implement an aclmode which only
applied the suid/sgid/sticky bit part of the argument to chmod and ignored
the rest, leaving it as is.
> Can you make that utility avoid the chmod?  The mode bits should come
> from the open(2)/creat(2), and there should be no need to set them again
> after setting the ACL.
I think there is an option not to copy the mode bits. But it does by
default, and I don''t really want to try and get every person on campus
who
mounts their files via NFSv4 from a linux system to try and change the
default behavior of a base utility. And they might even want that behavior
on the local filesystem.
> Such an app is broken.
Yes it is. But even if I could fix it (assuming it''s not a proprietary
binary), there would be another one after it. And then another. And
another. The only way to fully fix this issue for all possible instances of
bad defaults or broken applications is for the filesystem itself to enforce
it.
> But we''d have to extend NFSv4 and get the extension adopted and
> deployed.  There''s no chance of such a change being made in a
short
> period of time -- we''re talking years.
No need; based on your other email and a little code digging I think the
ignore option could be implemented entirely within the zfs code, allowing
manipulation of suid/sgid without changing ugo bits, with no change in
behavior or interface required by anything else.
> But is an application that sets an ACL and chmods ACL-aware?  How can the
> filesystem tell?  (Answer: it can''t really, as it may not be able
to
> relate the two operations.)
My definition of an ACL-aware application is one that *never* tries to
manipulate legacy mode bits on an object with a non-trivial ACL. Based on
that definition, it''s easy to tell :). And if an ACL aware application
wants to play with mode bits, first it should use the ACL API to set a
trivial ACL on the object, at which point chmod and mode bits would work
fine.
> As I wrote in that new sub-thread, I see no option that isn''t
surprising
> in some way.  My preference would be for what I labeled as option (b).
And I think you absolutely should be able to configure your fileserver to
implement your preference. Why shouldn''t I be able to configure my
fileserver to implement mine :)?


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On 02/26/10 17:38, Paul B. Henson wrote:
>> As I wrote in that new sub-thread, I see no option that isn''t
surprising
>> in some way.  My preference would be for what I labeled as option (b).
>
> And I think you absolutely should be able to configure your fileserver to
> implement your preference. Why shouldn''t I be able to configure my
> fileserver to implement mine :)?
acl-chmod interactions have been mishandled so badly in the past that i 
think a bit of experimentation with differing policies is in order.

Based on the amount of wailing I see around acls, I think that, based on 
personal experience with both systems, AFS had it more or less right and 
POSIX got it more or less wrong -- once you step into the world of acls, 
the file mode should be mostly ignored, and an accidental chmod should 
*not* destroy carefully crafted acls.

					- Bill

On Fri, 26 Feb 2010, Bill Sommerfeld wrote:
> acl-chmod interactions have been mishandled so badly in the past that i
> think a bit of experimentation with differing policies is in order.
I volunteer to help test discard and deny :). Heck, I volunteer to help
*implement* discard and deny...
> Based on the amount of wailing I see around acls, I think that, based on
> personal experience with both systems, AFS had it more or less right and
> POSIX got it more or less wrong -- once you step into the world of acls,
> the file mode should be mostly ignored, and an accidental chmod should
> *not* destroy carefully crafted acls.
We prototyped an AFS deployment for a while (it was the closest thing to
our existing DFS available). The location independence was great (I got
spoiled under DFS with the ability to transparently migrate data between
servers while in use), but the inability to apply an ACL to a file kind of
sucked. I guess you could have every file be in its own individual
subdirectory with the parent directory having a symlink to it to simulate
per-file ACL''s, but talk about kludgy.

I''m actually much happier with our ZFS deployment (other than a couple
of
ongoing unresolved scalability issues and this acl issue). But I can''t
agree with you more that an undesired chmod should not destroy carefully
crafted acls. Now if I could only get a ZFS engineer to share that
viewpoint :).


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On 2/26/2010 6:26 PM, Paul B. Henson wrote:
> On Fri, 26 Feb 2010, Nicolas Williams wrote:
>
>    
>> I believe we can do a bit better.
>>
>> A chmod that adds (see below) or removes one of r, w or x for owner is
a
>> simple ACL edit (the bit may turn into multiple ACE bits, but whatever)
>> modifying / replacing / adding owner@ ACEs (if there is one).  A
similar
>> chmod that affecting group bits should probably apply to group@ ACEs. 
A
>> similar chmod that affecting other should apply to any everyone@ ACEs.
>>      
> I don''t necessarily think that''s better; and I believe
that''s approximately
> the behavior you can already get with aclmode=passthrough.
>
> If something is trying to change permissions on an object with a
> non-trivial ACL using chmod, I think it''s safe to assume
that''s not what
> the original user who configured the ACL wants. At least, that would be
> safe to assume if the user had explicitly configured the hypothetical
> aclmode=deny or aclmode=ignore :).
>    
The problem with that, of course, is that it''s equally true in a 
pure-permissions world -- if I''m trying to change the permissions with 
chmod, it''s safe to assume that the new values aren''t what the
person
who originally configured the protections on that file wanted.  THAT''S 
WHY I''M CHANGING THEM!

So I don''t see how that''s a great argument for ignoring what I
do.

> Take, for example, a problem I''m currently having on Linux clients
mounting
> ZFS over NFSv4. Linux supports NFSv4, and even has a utility to manipulate
> NFSv4 ACL''s that works ok (but isn''t nearly as nice as
the ACL integrated
> chmod command in Solaris). However, the default behavior of the linux cp
> command is to try and copy the mode bits along with the file. So, I copy
> a file into zfs over the NFSv4 mount from some local location. The file is
> created and inherits the explicitly configured ACL from the parent
> directory; the cp command then does a chmod() on it and the ACL is broken.
> That''s not what I want, I configured that inheritable ACL for a
reason, and
> I want it respected regardless of the permissions of the file in its
> original location.
>    
Okay, but the argument goes the other way just as well -- when I run 
"chmod 6400 foobar", I want the permissions set that specific way, and
I
don''t want some magic background feature blocking me.  Particulary if 
"I" am a complex system of scripts that wasn''t even written
locally.
-- 

David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On 2/26/2010 6:52 PM, Paul B. Henson wrote:
> On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
>
>    
>> chown ddb /path/to/file
>> chmod 640 /path/to/file
>>      
>
>> I''ll tell you, if I type that and then find I (I''m
"ddb") *can''t* read the
>> file, I''m going to be REALLY unhappy.
>>      
> Then clearly you should configure your zfs filesystem in such a manner as
> to propogate the mode bit changes to the ACL. Which is currently, and even
> if the additional modes I''d like to see are implemented, would
remain the
> default. So unless you explicitly selected an alternative that better met
> your needs you could continue to ignore the differences between legacy mode
> bits and ACL''s.
>
>    
So, even if you''re willing to completely discard 30 years of legacy 
scripts and applications -- how to you propose that a NEW script or 
application should be written so as to work in this brave new environment?

>> The concept of having parts of a filesystem designated ACL-only and
parts
>> designated permissions-only leads to a total nightmare for utilities,
>> applications, and admin scripts of all kinds, so I don''t think
that can
>> be the answer.
>>      
> I disagree. If your deployment scenario is better served by preventing a
> ACL from being mangled by a well intentioned but destructive mapping of
> legacy permission mode bits, why shouldn''t that option be
available for
> you? Nobody would be forced to use it. It would probably be very unwise to
> set such an option on a root pool filesystem. But for a data filesystem
> with files accessed both via CIFS and NFSv4, the ability to keep *exactly*
> that same set of utilities, applications, and admin scripts from screwing
> up your ACL''s would be invaluable.
>    
And how should new utilities be written to take the place of the 30 
years of work you''re throwing out?  I don''t yet see how it can
be done.

>> Maybe you could make some rules, though.
>>      
> No, that''s been tried before. There is no good mapping from mode
bits to
> ACL''s. My understanding is that Sun is currently considering
getting rid of
> both the groupmask and passthrough aclmode''s (both examples of
trying to
> apply rules to map mode bit changes to ACL''s), leaving only
discard. I
> actually agree with that -- if you''re going to apply mode bit
changes to an
> object with an ACL, you might as well just get rid of it. However, in
> addition to discard, I think an option to just not *let* the ACL be
> destroyed should also be available.
>
>    
It doesn''t have to be complete to be extremely useful.

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

I was in the middle of a lengthy reply to this, which I''ve abandoned,
as it
can pretty much be summarized as "If you don''t want this behavior,
don''t
enable it."

It wouldn''t be the default, and if you didn''t want it, you
wouldn''t enable
it. Perhaps it might be enabled on some system you inherit, but in that
case whoever originally turned it on must have wanted it. So you''d
change
it to suit your needs. There''s *lotso* stuff on a hand-me-down system
that''s probably not configured the way you want :).

I''m not trying to force a particular behavior on anybody. I just want
an
optional behavior available to meet the specific needs of my deployment.


On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
> The problem with that, of course, is that it''s equally true in a
> pure-permissions world -- if I''m trying to change the permissions
with
> chmod, it''s safe to assume that the new values aren''t
what the person
> who originally configured the protections on that file wanted. 
THAT''S
> WHY I''M CHANGING THEM!
>
> So I don''t see how that''s a great argument for ignoring
what I do.
[...]
> Okay, but the argument goes the other way just as well -- when I run
> "chmod 6400 foobar", I want the permissions set that specific
way, and I
> don''t want some magic background feature blocking me.  Particulary
if
> "I" am a complex system of scripts that wasn''t even
written locally.
-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
> So, even if you''re willing to completely discard 30 years of
legacy
> scripts and applications -- how to you propose that a NEW script or
> application should be written so as to work in this brave new
> environment?
[...]
> And how should new utilities be written to take the place of the 30
> years of work you''re throwing out?  I don''t yet see how
it can be done.
First of all, you make a choice. Maybe the correct operation of some 30
year old script is most important to you. So you set an aclmode so it
works. But maybe making sure your sensitive data file doesn''t get
accidentally exposed to the world via a unexpected hidden chmod in a 30
year old script is more important than that script working. So you set an
aclmode so your ACL doesn''t get destroyed. It''s your choice.
Choice is
good.

Second, you''re not necessarily discarding all of those legacy
scripts/applications. You''re just making sure they don''t screw
up your
ACL''s. Take the example of the editor that chmod''s a file and
you don''t
want it to (but it''s a binary app and you can''t make it stop).
Configuring
zfs to ignore the chmod doesn''t break the application. The editor
continues
to edit fine. It just doesn''t destroy your ACL. Win-win.

If there''s some app/script for which changing permissions are essential
to
its operation, but it only understands mode bits, either the security
provided by mode bits is sufficient, so you configure aclmode so it works.
Or the security provided by mode bits isn''t sufficient, so you replace
the
app/script with one that understands ACLs. Using the published ACL API. man
-s 2 acl ;). You can claim it might be a lot of work, but I''m not sure
how
you could claim it can''t be done.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On 2/26/2010 8:45 PM, Paul B. Henson wrote:
> On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
>
>    
>> So, even if you''re willing to completely discard 30 years of
legacy
>> scripts and applications -- how to you propose that a NEW script or
>> application should be written so as to work in this brave new
>> environment?
>>      
> [...]
>    
>> And how should new utilities be written to take the place of the 30
>> years of work you''re throwing out?  I don''t yet see
how it can be done.
>>      
> First of all, you make a choice. Maybe the correct operation of some 30
> year old script is most important to you. So you set an aclmode so it
> works. But maybe making sure your sensitive data file doesn''t get
> accidentally exposed to the world via a unexpected hidden chmod in a 30
> year old script is more important than that script working. So you set an
> aclmode so your ACL doesn''t get destroyed. It''s your
choice. Choice is
> good.
>    

I think of using ACLs to extend extra access beyond what the permission 
bits grant.  Are you talking about using them to prevent things that the 
permission bits appear to grant?   Because so long as they''re only 
granting extended access, losing them can''t expose anything.  (It can 
still be tremendously inconvenient, of course; but I don''t see that it 
can create unintended access.)

I''m serious about not seeing how it''d be possible to write new
applications for this environment.  Most especially, new applications 
that also worked in a POSIX environment.  (Other than the brute force 
approach of completely separate code for the two environments.) It''s
not
just a problem for existing code.
> Second, you''re not necessarily discarding all of those legacy
> scripts/applications. You''re just making sure they don''t
screw up your
> ACL''s. Take the example of the editor that chmod''s a file
and you don''t
> want it to (but it''s a binary app and you can''t make it
stop). Configuring
> zfs to ignore the chmod doesn''t break the application. The editor
continues
> to edit fine. It just doesn''t destroy your ACL. Win-win.
>
> If there''s some app/script for which changing permissions are
essential to
> its operation, but it only understands mode bits, either the security
> provided by mode bits is sufficient, so you configure aclmode so it works.
> Or the security provided by mode bits isn''t sufficient, so you
replace the
> app/script with one that understands ACLs. Using the published ACL API. man
> -s 2 acl ;). You can claim it might be a lot of work, but I''m not
sure how
> you could claim it can''t be done.
>    
The problem, of course, is old apps that think they''re being especially
careful about replicating permissions properly.  That seems to be the 
scenario that breaks your ACLs.  Is there any way for a a bash script to 
replicate permissions in an ACL environment?  A Perl app?  A C app?  
Especially one that''s trying to be POSIX-portable?

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
> I think of using ACLs to extend extra access beyond what the permission
> bits grant.  Are you talking about using them to prevent things that the
> permission bits appear to grant?  Because so long as they''re only
> granting extended access, losing them can''t expose anything.
Consider the example of creating a file in a directory which has an
inheritable ACL for new files:

drwx--s--x+  2 henson   csupomona       4 Feb 27 09:21 .
            owner@:rwxpdDaARWcC--:-di---:allow
            owner@:rwxpdDaARWcC--:------:allow
            group@:--x---a-R-c---:-di---:allow
            group@:--x---a-R-c---:------:allow
         everyone@:--x---a-R-c---:-di---:allow
         everyone@:--x---a-R-c---:------:allow
            owner@:rwxpdDaARWcC--:f-i---:allow
            group@:--------------:f-i---:allow
         everyone@:--------------:f-i---:allow

When the ACL is respected, then regardless of the requested creation mode
or the umask, new files will have the following ACL:

-rw-------+  1 henson   csupomona       0 Feb 27 09:26 foo
            owner@:rw-pdDaARWcC--:------:allow
            group@:--------------:------:allow
         everyone@:--------------:------:allow

Now, let''s say a legacy application used a requested creation mode of
0644, and the current umask was 022, and the application calculated the
resultant mode and explicitly set it with chmod(0644):

-rw-r--r--+  1 henson   csupomona       0 Feb 27 09:26 foo
            owner@:----dDaARWcC--:------:allow
            group@:--------------:------:allow
         everyone@:--------------:------:allow
            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

A file which had an explicitly configured inherited ACL to be readable only
by the owner is now world readable. Ouch. On the other hard, in a
hypothetical world where aclmode=ignore existed, the undesired chmod would
have been ignored, and the security of the file would not have been
compromised.
> (It can still be tremendously inconvenient, of course;
End users don''t like inconvenience :). When their configured access
control
is broken, they call the help desk and scream a lot. Being able to
configure an environment which works for their needs would be very
valuable.
> I''m serious about not seeing how it''d be possible to
write new
> applications for this environment.
I think we''re just going to have to agree to disagree on this one.
> Is there any way for a a bash script to replicate permissions in an ACL
> environment?  A Perl app?  A C app?  Especially one that''s trying
to be
> POSIX-portable?
A script or application would work with ACL''s the exactly same way they
work with any other API, whether it be via calling command line tools, or
using native code to manipulate them.

I''m not saying it''s the best way to do it, but off the top of
my head
here''s bash code to copy an ACL on Solaris:

-rw-r--r--+  1 henson   csupomona       0 Feb 27 09:38 bar
            owner@:rw-pdDaARWcC--:------:allow
            group@:r-----a-R-c---:------:allow
         everyone@:r-----a-R-c---:------:allow
      group:cppweb:r-x---a-R-c---:------:allow

-rw-------+  1 henson   csupomona       0 Feb 27 09:38 foo
            owner@:rw-pdDaARWcC--:------:allow
            group@:--------------:------:allow
         everyone@:--------------:------:allow

$ chmod A=`ls -V bar | tail +2 | sed -e ''s/^ *//'' | tr
''\n'' ,` foo

-rw-r--r--+  1 henson   csupomona       0 Feb 27 09:38 foo
            owner@:rw-pdDaARWcC--:------:allow
            group@:r-----a-R-c---:------:allow
         everyone@:r-----a-R-c---:------:allow
      group:cppweb:r-x---a-R-c---:------:allow

For C apps, man -s 2 acl.

For perl apps, they can either go the bash route of calling out to OS
commands; or if there isn''t already a zfs acl module for perl allowing
you
to manipulate them directly from perl, I''d write one (like I did for
DFS
ACL''s back in the day --
http://www.csupomona.edu/~henson/archive/projects/DFS-Perl/)


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

"Paul B. Henson" <henson at acm.org>
writes:
> On Fri, 26 Feb 2010, David Dyer-Bennet wrote:
>> I think of using ACLs to extend extra access beyond what the
>> permission bits grant.  Are you talking about using them to prevent
>> things that the permission bits appear to grant?  Because so long as
>> they''re only granting extended access, losing them
can''t expose
>> anything.
>
> Consider the example of creating a file in a directory which has an
> inheritable ACL for new files:
why are you doing this?  it''s inherently insecure to rely on
ACL''s to
restrict access.  do as David says and use ACL''s to *grant* access.  if
needed, set permission on the file to 000 and use umask 777.
> drwx--s--x+  2 henson   csupomona       4 Feb 27 09:21 .
>             owner@:rwxpdDaARWcC--:-di---:allow
>             owner@:rwxpdDaARWcC--:------:allow
>             group@:--x---a-R-c---:-di---:allow
>             group@:--x---a-R-c---:------:allow
>          everyone@:--x---a-R-c---:-di---:allow
>          everyone@:--x---a-R-c---:------:allow
>             owner@:rwxpdDaARWcC--:f-i---:allow
>             group@:--------------:f-i---:allow
>          everyone@:--------------:f-i---:allow
>
> When the ACL is respected, then regardless of the requested creation
> mode or the umask, new files will have the following ACL:
>
> -rw-------+  1 henson   csupomona       0 Feb 27 09:26 foo
>             owner@:rw-pdDaARWcC--:------:allow
>             group@:--------------:------:allow
>          everyone@:--------------:------:allow
>
> Now, let''s say a legacy application used a requested creation mode
of
> 0644, and the current umask was 022, and the application calculated
> the resultant mode and explicitly set it with chmod(0644):
why is umask 022 when you want 077?  *that''s* your problem.

-- 
Kjetil T. Homme
Redpill Linpro AS - Changing the game

On Fri, Feb 26, 2010 at 03:00:29PM -0500, Miles Nordin
wrote:
> >>>>> "nw" == Nicolas Williams
<Nicolas.Williams at sun.com> writes:
> 
>     nw> What could we do to make it easier to use ACLs?
> 
> 1. how about AFS-style ones where the effective permission is the AND
>    of the ACL and the unix permission?  You might have to combine this
Yes, that sounds useful.  (Group modebits could be applied to all ACEs
that are neither owner@ nor everyone@ ACEs.)
>    with an inheritable-by-subdirectories umask setting so you could
>    create ACL-dominated lands of files that are all unix 777, but this
>    would stop clobbering difficult-to-recreate ACL''s as well as
>    unintended information leaking.
If users have private primary groups then you can have them run with
umask 007 or 002 and use set-gid and/or inherittable ACLs to ensure that
users can share files in specific directories.  (This is one reason that
I recommend always giving users their own private primary groups.)

Alternatively we could have a new mode bit to indicate that the group
bits of umask are to be treated as zero, or maybe assign this behavior
to the set-gid bit on ZFS.
> 2. define a standard API for them, add ability to replicate them to
>    [...]
That''d be nice.
> Maybe we''re beyond the point of no return for the first
suggestion.
Why?  It can just be another value of the aclmode property.

Nico
--

>>>>> "pbh" == Paul B Henson <henson at acm.org>
writes:
   pbh> the inability to apply an ACL to a file kind of sucked.

It was not a stupid limitation: You can still apply simple,
easily-understood UNIX ACL''s to files because the separate rulespaces
are ANDed together, but if you want baroque if-OR-then set-theory math
spaghetti you get to do it at most once per directory so it''s harder
for people to forget to what rules they''re subject, and it''s
not so
impractical or information-overload to display the rules along with a
list of files, like it is now where individual files need retarded and
difficult-to-parse-with-standard-tools multi-line stanzas or modal
dialog boxes to fully specify their access rules.  Also, the rights
that make sense for directories and files are not the same sets of
rights, so the AFS way your messy ACL''s only need to invent one set of
rights (the directory kind) and we needn''t bother pondering what list
of rights make sense for files.  However NFSv4 ACL''s wanted to be
Windows-compatible, so this must not have been an option.

Anyway, whether Unix ACL''s are a projection of complicated
ACL''s like
Solaris''s Windows-compatible ones, or a parallel independent system
like AFS was, is a completely separate decision from whether or not
files are allowed to have complicated ACL''s, too, or only directories.

I''ve said before I think your Samba use-case is way too specific: if
you can really fix your whole problem by commenting out one line and
you don''t care about anything else, then do it and STFU.  If you
can''t
make a simple fucking one-line change without causing all kinds of
management drama, then complain validly that you can''t currently get
both source code and paid support so where is the open in opensolaris
and why should you pay, which is just business and nothing to do with
design, instead of badgering persistently to flip this one line of
source in the direction you like without solving anything real.
Architecturally, we should be interested in something more general,
should we not?  And it sounds like you are.

It''s just sad because it feels like PHP, x86, HTML email and
``forums'''', FCoE, all this other crap that sounds nice to
fresh people
ignorant of the history: pandering to rabble that just wants what they
want and won''t think things through or imagine an alternate reality
fully instead of just the immediate itches it causes.  And I think
these NFSv4 ACL''s are the worst kind of rabble-pandering.

But, in spute of how it feels I''m mostly wrong here!  This should not
be the goal of ACL''s: the real result of the AFS experiment was, ``no
one competent cares about ACL''s that much.  only stupid windows admins
are obsessed with them, and they always set them wrong anyway---they
just like fiddling with all the knobs and bragging about what they
wrongly think the ACL''s are doing.'''' and secondly
``cross-domain
Kerberos == tl;dr''''.  so we''re not trying to design
the ultimate
post-Unix ACL system that respects our tradition without becoming
bogged down with brittle half-solutions, like I wish we were
doing---that debate died with the lack of interest in AFS.  With NFSv4
acl''s we''re jsut trying (failing so far imho but not w/o hope)
to
accomodate windows brain-damaged crappo without making the shell into
a second-class interface or breaking basic maintainability like
backups and subtree copies.  The real lesson of history is that hoping
for anything more is just going in circles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100301/c6ec2b89/attachment.bin>

>>>>> "dd" == David Dyer-Bennet <dd-b at
dd-b.net> writes:
    dd> Okay, but the argument goes the other way just as well -- when
    dd> I run "chmod 6400 foobar", I want the permissions set that
    dd> specific way, and I don''t want some magic background feature
    dd> blocking me.  

This will be true either way.  Even if chmod isn''t ignored, it will
reach into the nest of ACL''s and mangle them in some non-obvious way
with unpredictable consequences, and the mangling will be implemented
by a magical background feature.  AIUI if you really want the ACL''s
cleared and thus the ACL-ignorant intent of your chmod implemented,
you have to use a bunch of ACL-specific commands and pay attention to
inheritance as well.  What you''re asking is that something happen when
you do the chmod, but you don''t care WHAT happens so long as
it''s
SOMETHING.  This is really dumb.

    dd> Particulary if "I" am a complex system of scripts that
wasn''t
    dd> even written locally.

Yeah no I really think you''re on the wrong side of this one!

We must stop imagining we''re running on a Unix filesystem.  Once
you''ve added ACL''s you''re basically running on an
NTFS and should not
expect chmod to work any more than we expect it to do anything sane
through ntfs-3g.  The only reasonable goals are ``least
surprise'''' and
``maintainability''''.

Implementing Unix permissions as a special subcase of NFSv4 ACL''s is
good because it probably lets Windows clients make sense of the Unix
permissions better than Samba did?  but it''s a mistake to focus on
this one difficult case while disregarding the experiences of other
legacy clients, like for example on Linux if I mount something with
NFS **v3**, I get a bunch of + signs from GNU ls warning me there are
mysteryACL''s (POSIX ones!  more magical backgroudn translation!)
attached to every single file even though there aren''t, and this
breaks a couple obscure scripts, like genkernel IIRC.  The more
important downside though might be that it''s led to a lot of fuzzy
compromises in the way people think about the whole disaster, and
probably will forever as long as new people keep showing up to the
party: much of the value of our legacy was pissed away through this
hubris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100301/edbf5df1/attachment.bin>

On 03/01/10 13:50, Miles Nordin wrote:
>>>>>> "dd" == David Dyer-Bennet<dd-b at
dd-b.net>  writes:
>
>      dd>  Okay, but the argument goes the other way just as well -- when
>      dd>  I run "chmod 6400 foobar", I want the permissions
set that
>      dd>  specific way, and I don''t want some magic background
feature
>      dd>  blocking me.
>
> This will be true either way.  Even if chmod isn''t ignored, it
will
> reach into the nest of ACL''s and mangle them in some non-obvious
way
> with unpredictable consequences, and the mangling will be implemented
> by a magical background feature.
actually, you can be surprised even if there are no acls in use -- if, 
unbeknownst to you, some user has been granted file_dac_read or 
file_dac_write privilege, they will be able to bypass the file modes for 
read and/or for write.

Likewise if that user has been delegated zfs "send" rights on the 
filesystem the file is in, they''ll be able to read every bit of the
file.

					- Bill

--On Monday, March 01, 2010 03:21:42 PM -0600 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:
> On Fri, Feb 26, 2010 at 03:00:29PM -0500, Miles Nordin wrote:
>> >>>>> "nw" == Nicolas Williams
<Nicolas.Williams at sun.com> writes:
>>
>>     nw> What could we do to make it Re: [zfs-discuss] Who is using
ZFS
ACL''s in production?easier to use ACLs?
>>
>> 1. how about AFS-style ones where the effective permission is the AND
>>    of the ACL and the unix permission?  You might have to combine this
AFS applies its ACL, and the owner rwx bits on files (to everyone), and 
that''s it.  It doesn''t care who the owner and group are (*). 
New
directories inherit the ACL''s of their parents.  The only thing that 
manipulates AFS ACL''s are the interfaces explicitly intended for that 
purpose.

We''ve found this to work fairly well, with a few specific issues:

- As someone pointed out, we don''t have ACL''s on individual
files.  This
  is a limitation we''d like to eventually fix.

- There is no ability to set the inherited ACL for new subdirectories to
  something other than the ACL of the parent.  This means, for example,
  you can''t have a user home directory volume whose top-level gives x
  (in AFS, l) to everyone without new subdirs inheriting that.  This is
  also something we''d like to fix.

- Tools which second-guess access rights and refuse to offer or attempt
  operations they don''t think the user can do get confused.  Such tools
  are broken, and should be fixed.


(*) Well, mostly it doesn''t.  To allow dropboxes to work sanely, under 
certain circumstances some rights are implied for a file''s owner.  For 
example, if you have "insert" access on a directory, you implicitly
have
"read" and "write" ACL rights on files you own; this is
necessary because
the server is stateless and so does not know what files a client has
"open".

On Mon, March 1, 2010 15:50, Miles Nordin wrote:
>>>>>> "dd" == David Dyer-Bennet <dd-b at
dd-b.net> writes:
>
>     dd> Okay, but the argument goes the other way just as well -- when
>     dd> I run "chmod 6400 foobar", I want the permissions set
that
>     dd> specific way, and I don''t want some magic background
feature
>     dd> blocking me.
>
> This will be true either way.  Even if chmod isn''t ignored, it
will
> reach into the nest of ACL''s and mangle them in some non-obvious
way
> with unpredictable consequences, and the mangling will be implemented
> by a magical background feature.  AIUI if you really want the
ACL''s
> cleared and thus the ACL-ignorant intent of your chmod implemented,
> you have to use a bunch of ACL-specific commands and pay attention to
> inheritance as well.  What you''re asking is that something happen
when
> you do the chmod, but you don''t care WHAT happens so long as
it''s
> SOMETHING.  This is really dumb.
That''s getting pretty nasty.

If I sit and think, "I want read-write access for the owner, and read-only
access for people in the file''s group, and no access for anybody
else",
the natural thing to do is type "chmod 640 foobar" (sorry about the
original typo in the mode value!).

And I''m not arguing for any particular outcome; I''m arguing
that all
outcomes mentioned so far, and quite possibly all possible outcomes, will
be surprising and nasty from some significant point of view.  And I''m
trying to argue against privileging ACLs over mode values.
>     dd> Particulary if "I" am a complex system of scripts that
wasn''t
>     dd> even written locally.
>
> Yeah no I really think you''re on the wrong side of this one!
>
> We must stop imagining we''re running on a Unix filesystem.  Once
> you''ve added ACL''s you''re basically running on
an NTFS and should not
> expect chmod to work any more than we expect it to do anything sane
> through ntfs-3g.  The only reasonable goals are ``least
surprise'''' and
> ``maintainability''''.
So we''re trying to bury a massive flag-day change, no forwards or
backwards compatibility, under the fairly innocent heading "ACLs", eh?
Well, that''s one approach.  And it may be the best approach in some
ways.
However, I gotta say that things worked better with SAMBA, and that
specifically the ACLS has made converting to using CIFS a total nightmare.
 If I''d understood in advance I wouldn''t have done it.
> Implementing Unix permissions as a special subcase of NFSv4 ACL''s
is
> good because it probably lets Windows clients make sense of the Unix
> permissions better than Samba did?  but it''s a mistake to focus on
> this one difficult case while disregarding the experiences of other
> legacy clients, like for example on Linux if I mount something with
> NFS **v3**, I get a bunch of + signs from GNU ls warning me there are
> mysteryACL''s (POSIX ones!  more magical backgroudn translation!)
> attached to every single file even though there aren''t, and this
> breaks a couple obscure scripts, like genkernel IIRC.  The more
> important downside though might be that it''s led to a lot of fuzzy
> compromises in the way people think about the whole disaster, and
> probably will forever as long as new people keep showing up to the
> party: much of the value of our legacy was pissed away through this
> hubris.
Yeah, I think that''s kinda what I''m objecting to.

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On Sun, 28 Feb 2010, Kjetil Torgrim Homme wrote:
> why are you doing this?  it''s inherently insecure to rely on
ACL''s to
> restrict access.  do as David says and use ACL''s to *grant*
access.  if
> needed, set permission on the file to 000 and use umask 777.
Umm, it''s inherently insecure to rely on Access Control Lists to, well,
control access? Doesn''t that sound a bit off?

The only reason it''s insecure is because the ACL''s
don''t stand alone,
they''re propped up on a legacy chmod interoperability house of cards
which
frequently falls down.
> why is umask 022 when you want 077?  *that''s* your problem.
What I want is for my inheritable ACL''s not to be mixed in with legacy
concepts. ACL''s don''t have a umask. One of the benefits of
inherited ACL''s
is you don''t need to globally pick "022, let people see what
I''m up to" vs
"077, hide it all". You can just create files, with the confidence
that
every one you create will have the appropriate permissions as configured.

Except, of course, when they''re comingled with incompatible security
models. Basically, it sounds like you''re arguing I shouldn''t
try to fix
ACL/chmod issues because ACL''s are insecure because they have chmod
issues
8-/.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Mon, 1 Mar 2010, Nicolas Williams wrote:
> Yes, that sounds useful.  (Group modebits could be applied to all ACEs
> that are neither owner@ nor everyone@ ACEs.)
That sounds an awful lot like the POSIX mask_obj, which was the bane of my
previous filesystem, DFS, and which, as it seems history repeats itself, I
was also unable to get an option implemented to ignore it and allow
ACL''s
to work without impediment.
> If users have private primary groups then you can have them run with
> umask 007 or 002 and use set-gid and/or inherittable ACLs to ensure that
> users can share files in specific directories.  (This is one reason that
> I recommend always giving users their own private primary groups.)
The only reason for the recommendation to give users their own private
primary groups is because of the lack of flexibility of the umask/mode bits
security model. In an environment with inheritable ACL''s (that
aren''t
subject to being violated by that legacy security model) there''s no
real
need.
> Alternatively we could have a new mode bit to indicate that the group
> bits of umask are to be treated as zero, or maybe assign this behavior
> to the set-gid bit on ZFS.
So rather than a nice simple option granting ACL''s immunity from
umask/mode
bits baggage, another attempted mapping/interaction?

If you only ever access ZFS via CIFS from windows clients, you can have a
pure ACL model. Why should access via local shell or NFSv4 be a poor
stepchild and chained down with legacy semantics that make it exceedingly
difficult to actually use ACL''s for their intended purpose?

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

"Paul B. Henson" <henson at acm.org> writes:
> On Sun, 28 Feb 2010, Kjetil Torgrim Homme wrote:
>
>> why are you doing this?  it''s inherently insecure to rely on
ACL''s to
>> restrict access.  do as David says and use ACL''s to *grant*
access.
>> if needed, set permission on the file to 000 and use umask 777.
>
> Umm, it''s inherently insecure to rely on Access Control Lists to,
> well, control access? Doesn''t that sound a bit off?
no.  what happens when an NFS client without ACL support mounts your
filesystem?  your security is blown wide open.  the filemode should
reflect the *least* level of access.  if the filemode on its own allows
more access, then you''ve lost.
> The only reason it''s insecure is because the ACL''s
don''t stand alone,
> they''re propped up on a legacy chmod interoperability house of
cards
> which frequently falls down.
not if you do it right.
>> why is umask 022 when you want 077?  *that''s* your problem.
>
> What I want is for my inheritable ACL''s not to be mixed in with
legacy
> concepts. ACL''s don''t have a umask. One of the benefits
of inherited
> ACL''s is you don''t need to globally pick "022, let
people see what I''m
> up to" vs "077, hide it all". You can just create files,
with the
> confidence that every one you create will have the appropriate
> permissions as configured.
if your ACLs are completely specified and give proper access on their
own, and you''re using aclmode=passthrough, "chmod -R 000 /"
will not
harm your system.

if you have rogue processes doing "chmod a+rwx" or other nonsense, you
need to fix the rogue process, that''s not an ACL problem or a problem
with traditional Unix permissions.
> Except, of course, when they''re comingled with incompatible
security
> models. Basically, it sounds like you''re arguing I
shouldn''t try to
> fix ACL/chmod issues because ACL''s are insecure because they have
> chmod issues 8-/.
not at all.  you just have to use them correctly.

-- 
Kjetil T. Homme
Redpill Linpro AS - Changing the game

On Mon, March 1, 2010 23:04, Paul B. Henson wrote:
>> If users have private primary groups then you can have them run with
>> umask 007 or 002 and use set-gid and/or inherittable ACLs to ensure
that
>> users can share files in specific directories.  (This is one reason
that
>> I recommend always giving users their own private primary groups.)
>
> The only reason for the recommendation to give users their own private
> primary groups is because of the lack of flexibility of the umask/mode
> bits
> security model. In an environment with inheritable ACL''s (that
aren''t
> subject to being violated by that legacy security model) there''s
no real
> need.
Hmmm; the "lack of flexibility" you talk about comes from not using
the
security model sensibly -- having per-person groups is very useful in that
security model.

You see it as a "legacy security model"; but for me it''s the
primary
security model, with ACLs as an add-on.   It''s the only one
that''s
supported across the various ways of sharing the disks.  In the end,
Solaris is one player in the POSIX world, and cutting yourself off from
that would be very limiting.
>> Alternatively we could have a new mode bit to indicate that the group
>> bits of umask are to be treated as zero, or maybe assign this behavior
>> to the set-gid bit on ZFS.
>
> So rather than a nice simple option granting ACL''s immunity from
> umask/mode
> bits baggage, another attempted mapping/interaction?
>
> If you only ever access ZFS via CIFS from windows clients, you can have a
> pure ACL model. Why should access via local shell or NFSv4 be a poor
> stepchild and chained down with legacy semantics that make it exceedingly
> difficult to actually use ACL''s for their intended purpose?
It''s precisely to avoid having shell access being a poor stepchild that
I''m resisting ACLs.  As currently implemented, they relegate my primary
access to the system to second-class status.

And NFSv4 is mostly a rumor in my universe; NFSv2 and v3 are what people
actually use.

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

I haven''t been really closely following this discussion, but I might
have a solution.

A quick glance at ''man chmod(1)'' will show that there is an
unused bit
in the file mask, namely ''7000''. This has been there for quite
a long
time. I discovered it in ''94 when a student accidentally set it on her
home directory on HP-UX. Several hours of reading man pages later, I
discovered a ''-H'' option to ''ls'' which
showed "hidden files". It seems
that HP decided to use this unused bit to "hide" files and rewrote a
few binaries (ls, chmod, etc..) to support it.

Why not do the same sort of thing and use that extra bit to flag a
file, or directory, as being an ACL only file and will negate the rest
of the mask? That accomplishes what Paul is looking for, without
breaking the existing model for those that need/wish to continue to
use it?

No mad proliferation of private primary groups or bizarre scripted
workaround needed.

fpsm

On Tue, Mar 2, 2010 at 12:04 AM, Paul B. Henson <henson at acm.org>
wrote:
> On Mon, 1 Mar 2010, Nicolas Williams wrote:
>
>> Yes, that sounds useful. ?(Group modebits could be applied to all ACEs
>> that are neither owner@ nor everyone@ ACEs.)
>
> That sounds an awful lot like the POSIX mask_obj, which was the bane of my
> previous filesystem, DFS, and which, as it seems history repeats itself, I
> was also unable to get an option implemented to ignore it and allow
ACL''s
> to work without impediment.
>
>> If users have private primary groups then you can have them run with
>> umask 007 or 002 and use set-gid and/or inherittable ACLs to ensure
that
>> users can share files in specific directories. ?(This is one reason
that
>> I recommend always giving users their own private primary groups.)
>
> The only reason for the recommendation to give users their own private
> primary groups is because of the lack of flexibility of the umask/mode bits
> security model. In an environment with inheritable ACL''s (that
aren''t
> subject to being violated by that legacy security model) there''s
no real
> need.
>
>> Alternatively we could have a new mode bit to indicate that the group
>> bits of umask are to be treated as zero, or maybe assign this behavior
>> to the set-gid bit on ZFS.
>
> So rather than a nice simple option granting ACL''s immunity from
umask/mode
> bits baggage, another attempted mapping/interaction?
>
> If you only ever access ZFS via CIFS from windows clients, you can have a
> pure ACL model. Why should access via local shell or NFSv4 be a poor
> stepchild and chained down with legacy semantics that make it exceedingly
> difficult to actually use ACL''s for their intended purpose?
>
> --
> Paul B. Henson ?| ?(909) 979-6361 ?| ?http://www.csupomona.edu/~henson/
> Operating Systems and Network Analyst ?| ?henson at csupomona.edu
> California State Polytechnic University ?| ?Pomona CA 91768
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>

On 2 March 2010 08:13, Fredrich Maney <fredrichmaney at gmail.com>
wrote:
> I haven''t been really closely following this discussion, but I
might
> have a solution.
>
> A quick glance at ''man chmod(1)'' will show that there is
an unused bit
> in the file mask, namely ''7000''.
Isn''t that just like having setuid + setgid + sticky ? sticky is no
more used that much today on files (but it is on directories) -- I
don''t think we are "allowed" to play with it?
Or you meant 8000?


       -  Enrico

Logically it would be setuid + setgid + sticky, but it is not defined
in the man page and I don''t have the ability to read through the
applicable source code. If it''s not available, then I retract my
suggestion, and instead suggest that the man pages need to be updated.
:)

According to the man page, the valid values for the mask are 0-7 in 4
places, so 8000 would not be a valid value.

fpsm

On Tue, Mar 2, 2010 at 12:34 PM, ep <perlae at tcd.ie>
wrote:
> On 2 March 2010 08:13, Fredrich Maney <fredrichmaney at gmail.com>
wrote:
>> I haven''t been really closely following this discussion, but I
might
>> have a solution.
>>
>> A quick glance at ''man chmod(1)'' will show that there
is an unused bit
>> in the file mask, namely ''7000''.
>
> Isn''t that just like having setuid + setgid + sticky ? sticky is
no
> more used that much today on files (but it is on directories) -- I
> don''t think we are "allowed" to play with it?
> Or you meant 8000?
>
>
> ? ? ? - ?Enrico
>

On 2 March 2010 10:35, Fredrich Maney <fredrichmaney at gmail.com>
wrote:
> Logically it would be setuid + setgid + sticky, but it is not defined
> in the man page and I don''t have the ability to read through the
> applicable source code. If it''s not available, then I retract my
> suggestion, and instead suggest that the man pages need to be updated.
> :)
Well, I don''t think the man page needs to list all possible
combinations :)
sticky bit , setuid bit and setgid bit are all described. As I said,
the sticky bit is little if not used for regular files, but it has an
important semantic for directories:

 If a directory is writable and has S_ISVTX (the sticky  bit)
     set,  files  within that directory can be removed or renamed
     only if one or more of the following is true (see  unlink(2)
     and rename(2)):

         o    the user owns the file

         o    the user owns the directory

         o    the file is writable by the user

         o    the user is a privileged use


I would not go with "overloading" something that was not meant to be
used this way, especially since there are other possible solutions.
But, obviously, my opinion :)
>
> According to the man page, the valid values for the mask are 0-7 in 4
> places, so 8000 would not be a valid value.
Yes, I know, which is why I wondered if you meant to actually use a
bit that is not meant to be used.
Got also a bit misled by "bit", probably. :)


           -  Enrico

On 03/02/10 08:13, Fredrich Maney wrote:
> Why not do the same sort of thing and use that extra bit to flag a
> file, or directory, as being an ACL only file and will negate the rest
> of the mask? That accomplishes what Paul is looking for, without
> breaking the existing model for those that need/wish to continue to
> use it?
While we''re designing on the fly: Another possibility would be to use
an
additional umask bit or two to influence the mode-bit - acl interaction.

						- Bill

I strongly suggest that folks who are thinking about this examine what 
NetApp does when exporting NTFS security model qtrees via NFS. It 
constructs a mostly bogus set of POSIX permission info based on the ACL. 
All access is enforced based on the actual ACL. Sadly for NFSv3 clients 
there is no way to see what the actual ACL is, but it is properly enforced.

-- 
Carson

On 02 March, 2010 - Carson Gaspar sent me these 0,5K bytes:
> I strongly suggest that folks who are thinking about this examine what  
> NetApp does when exporting NTFS security model qtrees via NFS. It  
> constructs a mostly bogus set of POSIX permission info based on the ACL.  
> All access is enforced based on the actual ACL. Sadly for NFSv3 clients  
> there is no way to see what the actual ACL is, but it is properly 
> enforced.
ZFS recently stopped doing something similar to this (faking POSIX draft
ACLs), because it can cause data (ACL) corruption.

Client sees a faked ACL over NFS, modifies it and sends it back..

/Tomas
-- 
Tomas ?gren, stric at acc.umu.se, http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Ume?
`- Sysadmin at {cs,acc}.umu.se

Tomas ?gren wrote:
> On 02 March, 2010 - Carson Gaspar sent me these 0,5K bytes:
> 
>> I strongly suggest that folks who are thinking about this examine what
>> NetApp does when exporting NTFS security model qtrees via NFS. It  
>> constructs a mostly bogus set of POSIX permission info based on the
ACL.
>> All access is enforced based on the actual ACL. Sadly for NFSv3 clients
>> there is no way to see what the actual ACL is, but it is properly 
>> enforced.
> 
> ZFS recently stopped doing something similar to this (faking POSIX draft
> ACLs), because it can cause data (ACL) corruption.
> 
> Client sees a faked ACL over NFS, modifies it and sends it back..
That''s only a problem if you allow the client to modify the bogus data,
so don''t do that ;-)

NetApp does _not_ expose an ACL via NFSv3, just old school POSIX 
mode/owner/group info. I don''t know how NetApp deals with chmod, but
I''m
sure it''s documented.

-- 
Carson

On Tue, Mar 02, 2010 at 11:10:52AM -0800, Bill Sommerfeld
wrote:
> On 03/02/10 08:13, Fredrich Maney wrote:
> >Why not do the same sort of thing and use that extra bit to flag a
> >file, or directory, as being an ACL only file and will negate the rest
> >of the mask? That accomplishes what Paul is looking for, without
> >breaking the existing model for those that need/wish to continue to
> >use it?
> 
> While we''re designing on the fly:
Heh.
>                                   Another possibility would be to use an 
> additional umask bit or two to influence the mode-bit - acl interaction.
Well, I think the bit, if we must have one, belongs in the filesystem
objects that have ACLs, as opposed to processes.  There may be no umask
to apply in remote access cases, so using a process attribute is likely
to result in different behavior according to the access protocol and
client.  That might not be surprising for the CIFS case, but it
certainly would be for the NFS case.

But also I think it''s the owner of an object that should decide what
happens to the object''s ACL on chmod rather than random programs and
user environments.

We might need multiple bits, but we do have multiple bits to play with
in mode_t.  The main issue with adding mode_t bits is going to be: will
apps handle the appearance of new mode_t bits correctly?  I suspect that
they will, or at least that we''d condier it a bug if they
didn''t.  Or we
could add a new file attribute.

But given cheap datasets, why not settle for a suitable dataset property
as a starting point.  I.e., maybe we could play with aclmode a little
more.

Nico
--

carson at taltos.org said:
> NetApp does _not_ expose an ACL via NFSv3, just old school POSIX 
mode/owner/
> group info. I don''t know how NetApp deals with chmod, but
I''m  sure it''s
> documented. 
The answer is, "It depends."  If the NetApp volume is NTFS-only
permissions,
then chmod from the Unix/NFS side doesn''t work, and you can only
manipulate
permissions from Windows clients..  If it''s a "mixed"
security-style volume,
chmod from the Unix/NFS side will delete the NTFS ACL''s, and the SMB
clients
will see faked-up ACL''s that match the new POSIX permissions. 
Whichever side
made the most recent change will be in effect.

Newer OnTAP versions have an optional setting which overrides this effect
of chmod if NFSv4 is in effect on mixed-security volumes, and instead tries
to mirror the ACL''s as identically as possible to both kinds of
clients.
Poor old NFSv3 and older clients still see gibberish POSIX permissions,
but the least privilege available in ACL''s is enforced by the filer.

BTW, our experience has been that NFSv4 on NetApp does not work very well,
and NetApp support folks have advised us to not use it in order to avoid
crashing the filer.  They of course blame the various incompatible NFSv4
client implementations out there....

Regards,

Marion

On Tue, Mar 02, 2010 at 11:42:30AM -0800, Carson Gaspar
wrote:
> 
> NetApp does _not_ expose an ACL via NFSv3, just old school POSIX
> mode/owner/group info. I don''t know how NetApp deals with chmod,
but
> I''m sure it''s documented.
I can''t get a chmod to succeed in that situation.  This particular file
doesn''t have a custom ACL, but that doesn''t seem to matter.

# touch foo
# chmod 644 foo
chmod: WARNING: can''t change foo
# ls -l foo
-rwxrwxrwx   1 root     other          0 Mar  2 12:36 foo

-- 
Darren

On Tue, 2 Mar 2010, Kjetil Torgrim Homme wrote:
> no.  what happens when an NFS client without ACL support mounts your
> filesystem?  your security is blown wide open.  the filemode should
> reflect the *least* level of access.  if the filemode on its own allows
> more access, then you''ve lost.
Say what?

If you''re using secure NFS, access control is handled on the server
side.
If an NFS client that doesn''t support ACL''s mounts the
filesystem, it will
have whatever access the user is supposed to have, the lack of ACL support
on the client is immaterial.

On the other hand, if you''re using AUTH_SYS, you don''t care
about security
in the first place so there''s no real point in worrying about it.
> if your ACLs are completely specified and give proper access on their
> own, and you''re using aclmode=passthrough, "chmod -R 000
/" will not
> harm your system.
Actually, it will destroy the three special ACE''s, user@, group@, and
everyone at . On the other hand, with a hypothetical aclmode=ignore or
aclmode=deny, such a chmod would indeed not harm the system.
> if you have rogue processes doing "chmod a+rwx" or other
nonsense, you
> need to fix the rogue process, that''s not an ACL problem or a
problem
> with traditional Unix permissions.
What I have are processes that don''t know about ACL''s. Are
they broken? Not
in and of themselves, they are simply incompatible with a security model
they are unaware of. Why on earth would I want to go and try to make every
single application in the world ACL aware/compatible instead of simply
having a filesystem which I can configure to ignore any attempt to
manipulate legacy permissions?
> not at all.  you just have to use them correctly.
I think we''re just not on the same page on this; while I am not saying
I''m
on the right page, it does seem you need to do a little more reading up on
how ACL''s work.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Mon, Mar 01, 2010 at 09:04:58PM -0800, Paul B. Henson
wrote:
> On Mon, 1 Mar 2010, Nicolas Williams wrote:
> > Yes, that sounds useful.  (Group modebits could be applied to all ACEs
> > that are neither owner@ nor everyone@ ACEs.)
> 
> That sounds an awful lot like the POSIX mask_obj, which was the bane of my
> previous filesystem, DFS, and which, as it seems history repeats itself, I
> was also unable to get an option implemented to ignore it and allow
ACL''s
> to work without impediment.
Alternatively group modebits apply to only the group@ ACEs.  This could
be just yet another option.

If no modebits were to apply to ACEs with subjects other than
owner@/group@/everyone@ (what about subjects that match the file''s
owner/group but aren''t owner@/group@?) then there''d be no way
to use
modebits as a big filter for ACLs.  This is why I proposed the above.
> > If users have private primary groups then you can have them run with
> > umask 007 or 002 and use set-gid and/or inherittable ACLs to ensure
that
> > users can share files in specific directories.  (This is one reason
that
> > I recommend always giving users their own private primary groups.)
> 
> The only reason for the recommendation to give users their own private
> primary groups is because of the lack of flexibility of the umask/mode bits
> security model. In an environment with inheritable ACL''s (that
aren''t
> subject to being violated by that legacy security model) there''s
no real
> need.
All reasons I have for it really come back to this: the idea of a
primary group and file group is an anachronism from back when ACLs (and
supplementary group memberships!) were overkill.  Think back to the days
when the AT&T labs were the only place where Unix ran and Unix had a
user base in the tens of users.  We''re stuck with the notion of a
primary group (Windows seems to have it for interop with POSIX).  The
way to make the best of that situation is to give every user their own
private group.
> > Alternatively we could have a new mode bit to indicate that the group
> > bits of umask are to be treated as zero, or maybe assign this behavior
> > to the set-gid bit on ZFS.
> 
> So rather than a nice simple option granting ACL''s immunity from
umask/mode
> bits baggage, another attempted mapping/interaction?
You have a good idea of what is "simple" for your use case.  Your use
case also appears to be greatly influenced by what we could (should, do)
consider to be a bug in Samba.  Your idea of "simple" may not match
every one else''s.  And your idea of "simple" might well
differ if that
one application didn''t use chmod() at all.

Personally I don''t see a simple, non-surprising solution.  I see a set
of solutions that one could pick from.  In all cases I think we need a
way to synthesize modebits from ACLs (e.g., for objects created via
protocols that have no conception of modebits but have a conception of
ACLs) -- that''s a difficult problem because any algorithm for doing
that
will necessarily be lossy in many cases.
> If you only ever access ZFS via CIFS from windows clients, you can have a
> pure ACL model. Why should access via local shell or NFSv4 be a poor
> stepchild and chained down with legacy semantics that make it exceedingly
> difficult to actually use ACL''s for their intended purpose?
I am certainly not advocating that.

Nico
--

On Tue, 2 Mar 2010, David Dyer-Bennet wrote:
> Hmmm; the "lack of flexibility" you talk about comes from not
using the
> security model sensibly -- having per-person groups is very useful in
> that security model.
I have 70 odd thousand users. Why would I want to also have 70 thousand
groups with only one user in each one? From an authorization perspective,
the user and group are identical. The absolute only reason to implement
such a duplicative environment is so you can have one umask, but still be
able to control whether or not someone other than the user gets permissions
on new files. In a world with inheritable ACL''s, you don''t
need to do that.
> You see it as a "legacy security model"; but for me it''s
the primary
> security model, with ACLs as an add-on.  It''s the only one
that''s
> supported across the various ways of sharing the disks. In the end,
> Solaris is one player in the POSIX world, and cutting yourself off from
> that would be very limiting.
If the design requirements of your filesystem require backward
interoperability, then yes. On the other hand, if they don''t, and you
would
be better served with a pure-ACL deployment, why hold yourself down with
the chains of a security model you don''t need?
> It''s precisely to avoid having shell access being a poor stepchild
that
> I''m resisting ACLs.  As currently implemented, they relegate my
primary
> access to the system to second-class status.
How so? Do you mean operating in a shell on a system with no ACL support?
> And NFSv4 is mostly a rumor in my universe; NFSv2 and v3 are what people
> actually use.
Really? We''ve deployed NFSv4 here, and other than this ACL/chmod issue
it''s
working great. I think I''d rather design my future technology based on
the
needs and possibilities of the future, not on the past. From that
perspective, why should Sun bother to work on NFSv4 at all if nobody uses
it.

Again, I''m not advocating removing any current functionality or
depriving
you of anything you currently have. I''m simply requesting an additional
feature set that would be very useful for some deployments. I''m not
really
sure why people keep arguing about why it would not be good for their
deployment, and considering such a reason it should not be implemented --
that seems a bit self-centered.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Tue, 2 Mar 2010, Bill Sommerfeld wrote:
> While we''re designing on the fly: Another possibility would be to
use an
> additional umask bit or two to influence the mode-bit - acl interaction.
I''ve think trying to continue shoving a square page into a round hole
is
simply the wrong thing to do; rather than trying to force together
different security models, allow an option getting rid of the security
model not desired, letting the other one "just work".


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Tue, 2 Mar 2010, Marion Hakanson wrote:
> The answer is, "It depends."  If the NetApp volume is NTFS-only
> permissions, then chmod from the Unix/NFS side doesn''t work, and
you can
> only manipulate permissions from Windows clients..  If it''s a
"mixed"
> security-style volume, chmod from the Unix/NFS side will delete the NTFS
> ACL''s, and the SMB clients will see faked-up ACL''s that
match the new
> POSIX permissions.  Whichever side made the most recent change will be in
> effect.
We evaluated NetApp before selecting ZFS, my general summary of their
permissions implementation is "messy, confusing, and inconsistent".
Even
with these chmod issues, the ZFS implementation is far superior,
particularly for sharing the same ACL''s between NFSv4 and CIFS.
> BTW, our experience has been that NFSv4 on NetApp does not work very
> well, and NetApp support folks have advised us to not use it in order to
> avoid crashing the filer.  They of course blame the various incompatible
> NFSv4 client implementations out there....
Indeed; other than a few minor issues here and there, NFSv4 with Solaris
servers, and both Linux and Solaris clients has been working great.

And I don''t really think a "bad client" should be able to
crash the server;
regardless of the client problems that''s a server bug.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

Yes. Yes. Yes. I agree with every one of your points in this message :).

On Tue, 2 Mar 2010, Nicolas Williams wrote:
> Well, I think the bit, if we must have one, belongs in the filesystem
> objects that have ACLs, as opposed to processes.  There may be no umask
> to apply in remote access cases, so using a process attribute is likely
> to result in different behavior according to the access protocol and
> client.  That might not be surprising for the CIFS case, but it certainly
> would be for the NFS case.
>
> But also I think it''s the owner of an object that should decide
what
> happens to the object''s ACL on chmod rather than random programs
and user
> environments.
>
> We might need multiple bits, but we do have multiple bits to play with in
> mode_t.  The main issue with adding mode_t bits is going to be: will apps
> handle the appearance of new mode_t bits correctly?  I suspect that they
> will, or at least that we''d condier it a bug if they
didn''t.  Or we could
> add a new file attribute.
>
> But given cheap datasets, why not settle for a suitable dataset property
> as a starting point.  I.e., maybe we could play with aclmode a little
> more.

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

"Paul B. Henson" <henson at acm.org> writes:
> On Tue, 2 Mar 2010, Kjetil Torgrim Homme wrote:
>
>> no.  what happens when an NFS client without ACL support mounts your
>> filesystem?  your security is blown wide open.  the filemode should
>> reflect the *least* level of access.  if the filemode on its own allows
>> more access, then you''ve lost.
>
> Say what?
>
> If you''re using secure NFS, access control is handled on the
server
> side.  If an NFS client that doesn''t support ACL''s mounts
the
> filesystem, it will have whatever access the user is supposed to have,
> the lack of ACL support on the client is immaterial.
this is true for AUTH_SYS, too, sorry about the bad example.  but it
doesn''t really affect my point.  if you just consider the filemode to
be
the lower bound for access rights, aclmode=passthrough will not give you
any nasty surprises regardless of what clients do, *and* an ACL-ignorant
client will get the behaviour it needs and wants.  win-win!
>> if your ACLs are completely specified and give proper access on their
>> own, and you''re using aclmode=passthrough, "chmod -R 000
/" will not
>> harm your system.
>
> Actually, it will destroy the three special ACE''s, user@, group@,
and
> everyone at .  On the other hand, with a hypothetical aclmode=ignore or
> aclmode=deny, such a chmod would indeed not harm the system.
you''re not using those, are you?  they are a direct mapping of the old
style permissions, so it would be pretty weird if they were allowed to
diverge.
>> if you have rogue processes doing "chmod a+rwx" or other
nonsense, you
>> need to fix the rogue process, that''s not an ACL problem or a
problem
>> with traditional Unix permissions.
>
> What I have are processes that don''t know about ACL''s.
Are they
> broken? Not in and of themselves, they are simply incompatible with a
> security model they are unaware of.
you made that model.
> Why on earth would I want to go and try to make every single
> application in the world ACL aware/compatible instead of simply having
> a filesystem which I can configure to ignore any attempt to manipulate
> legacy permissions?
you don''t have to.  just subscribe to the principle of least security,
and it just works.
>> not at all.  you just have to use them correctly.
>
> I think we''re just not on the same page on this; while I am not
saying
> I''m on the right page, it does seem you need to do a little more
> reading up on how ACL''s work.
nice insult.

-- 
Kjetil T. Homme
Redpill Linpro AS - Changing the game

BTW, it should be relatively easy to implement aclmode=ignore and
aclmode=deny, if you like.

 - $SRC/common/zfs/zfs_prop.c needs to be updated to know about the new
   values of aclmode.

 - $SRC/uts/common/fs/zfs/zfs_acl.c:zfs_acl_chmod()''s callers need to
be
   modified:

    - in the create path if zfs_acl_chmod() gets called then you can''t
      ignore nore deny the mode;
    - zfs_acl_chmod_setattr() should call neither zfs_acl_node_read()
      nor zfs_acl_chmod() if aclmode=ignore or aclmode=deny
    - in all other paths you zfs_acl_chmod() should do what it should do

 - $SRC/uts/common/fs/zfs/zfs_vnops.c:zfs_setattr() may need some
   updates too, e.g., to not call zfs_aclset_common() in the case of
   aclmode=ignore -- you''ll probably have to play around to figure out
   what else.

Nico
--

I find myself agreeing with Paul on this one. We allow people to
choose between filesystems, volume managers, password encryption
algorithims, profiles, etc. Why not allow them to pick one file
security model, another, or both?

Now, of course, the devil is in the details of implementation. Do we
make it system wide (a la a setting in some file in /etc/security) or
zpool of zfs dataset specific? I would think the most clean way would
be to put it at the dataset level.

fpsm

On Tue, Mar 2, 2010 at 4:13 PM, Paul B. Henson <henson at acm.org>
wrote:
> On Tue, 2 Mar 2010, Bill Sommerfeld wrote:
>
>> While we''re designing on the fly: Another possibility would be
to use an
>> additional umask bit or two to influence the mode-bit - acl
interaction.
>
> I''ve think trying to continue shoving a square page into a round
hole is
> simply the wrong thing to do; rather than trying to force together
> different security models, allow an option getting rid of the security
> model not desired, letting the other one "just work".
>
>
> --
> Paul B. Henson ?| ?(909) 979-6361 ?| ?http://www.csupomona.edu/~henson/
> Operating Systems and Network Analyst ?| ?henson at csupomona.edu
> California State Polytechnic University ?| ?Pomona CA 91768
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>

On Tue, 2 Mar 2010, Nicolas Williams wrote:
> If no modebits were to apply to ACEs with subjects other than
> owner@/group@/everyone@ (what about subjects that match the file''s
> owner/group but aren''t owner@/group@?) then there''d be no
way to use
> modebits as a big filter for ACLs.  This is why I proposed the above.
I''m not sure what you mean about using mode bits as a filter. Why would
you
want to use mode bits as a filter? I agree that for backwards
compatibility, a read only view of the mode bits expressing as closely as
possible the underlying ACL permissions is desirable; but when it comes to
actually evaluating access to the object, the mode bits simply should not
be involved. The ACL standing alone is sufficient to make a determination,
why complicate/confuse it?

As far as explicit user/group ACE''s that happen to be for the same
user/group as owns the object, there''s a clear definition for how the
ACL
should be interpreted. From a semantic point of view, a user:fred ACE is
identical to a user@ ACE if the owner is fred. There''s no need to
involve
mode bits in the matter.
> All reasons I have for it really come back to this: the idea of a primary
> group and file group is an anachronism from back when ACLs (and
> supplementary group memberships!) were overkill.
Perhaps, but the concept of a "file owner" and "file group",
along with the
special ACE''s, can still be useful, or at least used coherently.
> The way to make the best of that situation is to give every user their
> own private group.
That''s one possibility; basically equating user and user primary group
as
the same underlying authorization entity. Another possibility is what I do
here; all users share the same primary group, basically equating user
primary group with "has an account" (not necessarily the same as
everyone@,
as for some of access methods that would allow anyone in the world
unauthenticated access to an object). I wouldn''t necessarily say one or
the
other is "best", although my approach avoids 69,000+ extraneous groups
in
our deployment :).

I still say that the only reason to give each user their own private group
is because of the limitations of the umask/mode bits implementation, and if
those limitations were removed, it doesn''t make much sense anymore.
> You have a good idea of what is "simple" for your use case. Your
use case
> also appears to be greatly influenced by what we could (should, do)
> consider to be a bug in Samba.
Obviously I''m biased towards my needs ;), although in pursuit of such I
don''t believe I am making any claims that are not factual.

I''m not sure what Samba issue you are referring to. Are you referring
to my
inability to get it to not chmod stuff? If so, that issue is simply one
instance of the underlying problem I am trying to address, its existence
has no more or less influence to my goal than any other instance of the
same underlying issue. I have not declared that a bug, nor have I asked Sun
to do anything specifically about samba/chmod other than mentioning it as
an example in my proposal for allowing ACL''s to be chmod-free.

Or are you referring to the bug in which membership in more than 32 active
directory groups results in the setgroups() call failing in samba resulting
in the user having no supplementary group list at all? That issue has
nothing to do with ACL''s or chmod and is completely orthogonal to this
discussion.
> Your idea of "simple" may not match every one else''s. 
And your idea of
> "simple" might well differ if that one application
didn''t use chmod() at
> all.
The fact that samba belongs to the class of applications that is impacted
by acl/chmod interaction doesn''t really change my proposal.
I''ve actually
fixed my samba problem, as I believe I previously mentioned I preloaded a
shared library overloading chmod and making it a noop. If all I needed to
do was fix samba I''d be done. But I''d like to address the
entire class of
applications with similar issues at the one and only point at which they
can all be resolved at once -- the file system itself.
> Personally I don''t see a simple, non-surprising solution.  I see a
set of
> solutions that one could pick from.
And I''m not saying there is such a beast; only that the solution
I''m
proposing resolves one set of potential problems and should be seriously
considered as one of the set of solutions made available. I''ve got
nothing
against other solutions available for other people with other problems, 50
different aclmodes is fine by me. Perhaps you don''t recall, but I (only
semi-jokingly) suggested the ability to specify an aclmode "script" to
describe exactly how the interaction between chmod/mode bits/ACL''s be
implemented, allowing any conceivable solution to be implemented by anyone
who needed it.
> In all cases I think we need a way to synthesize modebits from ACLs
> (e.g., for objects created via protocols that have no conception of
> modebits but have a conception of ACLs) -- that''s a difficult
problem
> because any algorithm for doing that will necessarily be lossy in many
> cases.
It''s fairly easy to downconvert an ACL into mode bits, user@, group@,
and
everyone@ come pretty close. Making up a set of mode bits to feed to
non-ACL-aware applications makes perfect sense. My problem is going the
other way, trying to take a set of mode bits and somehow upscale it into an
ACL is broken for my needs. Yes, some people might need that capability,
and I absolutely support that they should have it -- but I''d like to
have
the capability to not have it.
> > If you only ever access ZFS via CIFS from windows clients, you can
have a
> > pure ACL model. Why should access via local shell or NFSv4 be a poor
> > stepchild and chained down with legacy semantics that make it
exceedingly
> > difficult to actually use ACL''s for their intended purpose?
>
> I am certainly not advocating that.
Good :). I am certainly not wedded to my proposal, if some other solution
is proposed that would meet my requirements, great. However, pretty much
all of the advice has boiled down to either "ACL''s are broken,
don''t use
them", or "why would you want to do *that*?", which
isn''t particularly
useful.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Tue, 2 Mar 2010, Nicolas Williams wrote:
> BTW, it should be relatively easy to implement aclmode=ignore and
> aclmode=deny, if you like.
I looked over the code some, and from an intuitive point of view it
didn''t
seem like it would be that hard; thanks for the pointers.

I''m absolutely willing to put my code where my mouth is, I''d
happily
implement this functionality myself. However, unless I can get it included
upstream, that''s not really going to resolve my problem. I
don''t think it
would be possible to replace the Solaris 10 kernel with my own locally
compiled one, and while I theoretically could for opensolaris, I doubt that
would be considered a supportable configuration. I''d certainly take
responsibility for any bugs with my own code, but I don''t really have
the
resources to support the entire kernel/OS on my own :(, and I''m pretty
sure
my management wants a phone number to call and an entity to point their
finger at ;).

I was kind of hoping to get some buy-in on the concept, but so far no luck.
I might still implement it just to show it can be done, but I don''t
currently have an opensolaris dev environment set up, and it seems like an
awful lot of initial investment just to be able to point to something and
say "Boy, it sure would be cool if they accepted that into the code
base"
:(.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Tue, 2 Mar 2010, Fredrich Maney wrote:
> We allow people to choose between filesystems, volume managers, password
> encryption algorithims, profiles, etc. Why not allow them to pick one
> file security model, another, or both?
Choice is good :).
> Now, of course, the devil is in the details of implementation. Do we make
> it system wide (a la a setting in some file in /etc/security) or zpool of
> zfs dataset specific? I would think the most clean way would be to put it
> at the dataset level.
My preference would be to implement as new aclmode options, so it would be
per dataset.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Tue, 2 Mar 2010, Kjetil Torgrim Homme wrote:
> this is true for AUTH_SYS, too, sorry about the bad example.
Technically I suppose the server actually makes the determination about
access, but given it makes it based blindly on whatever the client tells
it, it seems it''s really the client with the power.
> doesn''t really affect my point.  if you just consider the filemode
to be
> the lower bound for access rights, aclmode=passthrough will not give you
> any nasty surprises regardless of what clients do, *and* an ACL-ignorant
> client will get the behaviour it needs and wants.  win-win!
Lose-lose. I don''t get to avail of the full potential of expression
ACL''s
provide, and ACL-ignorant clients will get to screw up the permissions I
specified. Sorry, but on my data, I think the behavior I need and want
should override what some random application wants to do.
> you''re not using those, are you?  they are a direct mapping of the
old
> style permissions, so it would be pretty weird if they were allowed to
> diverge.
Why wouldn''t I use them? They''re a defined part of the ACL
standard, and
objects continue to have owners and group owners. I have no issue with read
only mode bits being synthesized from the special ACE''s and provided to
clients, my issue is having non-ACL aware apps trying to update mode bits
and that being translated into a lossy change to the ACL.
> you made that model.
Thanks for the compliment, but I''m afraid I did not contribute to
either
the original implementation of mode bits, nor windows CIFS ACL''s, nor
the
RFC for NFSv4 ACL''s, nor implementation thereof in ZFS.

Surely you''re not arguing that "mode bits" and
"ACL''s" are not different
security models?
> you don''t have to.  just subscribe to the principle of least
security,
> and it just works.
I don''t want "least security". I want "best
security". Again, you''re pretty
much saying I wouldn''t have a problem if I chose not to have a problem.
I''m
not quite sure what your point is. If my car engine caught on fire every
time I exceeded 50 mph, would you say that rather than taking it to the
dealer to get fixed, I should simply never exceed 50 mph?
> nice insult.
It wasn''t an insult, it was an objective observation. You have made
what I
believe to be factually incorrect claims about how ACL''s work and are
implemented.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

"Paul B. Henson" <henson at acm.org> writes:
> Good :). I am certainly not wedded to my proposal, if some other
> solution is proposed that would meet my requirements, great. However,
> pretty much all of the advice has boiled down to either
"ACL''s are
> broken, don''t use them", or "why would you want to do
*that*?", which
> isn''t particularly useful.
you haven''t demonstrated why the current capabilities are insufficient
for your requirements.  it''s a bit hard to offer advice for perceived
problems other than "reconsider your perception".

-- 
Kjetil T. Homme
Redpill Linpro AS - Changing the game

On Tue, 2 Mar 2010, Kjetil Torgrim Homme wrote:
> you haven''t demonstrated why the current capabilities are
insufficient
> for your requirements.  it''s a bit hard to offer advice for
perceived
> problems other than "reconsider your perception".
I think I''ve made it pretty clear that I want to control access by ACL,
and
not allow attempts to manipulate legacy mode bits to change the ACL, and
that given current capabilities it''s difficult to impossible to do so.
It
also seems clear from your responses you don''t think that''s an
appropriate
goal to be seeking. If you can offer alternative mechanisms within the
current capability set that can achive that goal I''d love to hear them;
but
claims that I wouldn''t have a problem if I didn''t consider the
current
state of affairs to be a problem aren''t particularly useful.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Tue, March 2, 2010 15:12, Paul B. Henson wrote:
> On Tue, 2 Mar 2010, David Dyer-Bennet wrote:
>
>> Hmmm; the "lack of flexibility" you talk about comes from not
using the
>> security model sensibly -- having per-person groups is very useful in
>> that security model.
>
> I have 70 odd thousand users. Why would I want to also have 70 thousand
> groups with only one user in each one? From an authorization perspective,
> the user and group are identical. The absolute only reason to implement
> such a duplicative environment is so you can have one umask, but still be
> able to control whether or not someone other than the user gets
> permissions
> on new files. In a world with inheritable ACL''s, you
don''t need to do
> that.
It''s the normal way to do it; not sure where in the Linux world it
arose,
but I first saw it in some early distribution.  It''s done automatically
by
"adduser".   In my perception, it''s "best
practice".  So the question is,
why do you NOT want to do it?
>> You see it as a "legacy security model"; but for me
it''s the primary
>> security model, with ACLs as an add-on.  It''s the only one
that''s
>> supported across the various ways of sharing the disks. In the end,
>> Solaris is one player in the POSIX world, and cutting yourself off from
>> that would be very limiting.
>
> If the design requirements of your filesystem require backward
> interoperability, then yes. On the other hand, if they don''t, and
you
> would
> be better served with a pure-ACL deployment, why hold yourself down with
> the chains of a security model you don''t need?
I can''t believe in that model.  If I buy it, every time I consider a
script set or application for use, I have to do extensive testing to
verify that it works in the model.  And I have to deal with users having
that problem on their own.  This is far, far too expensive to give any
serious consideration to.

This is why people hate flag-day changes.
>> It''s precisely to avoid having shell access being a poor
stepchild that
>> I''m resisting ACLs.  As currently implemented, they relegate
my primary
>> access to the system to second-class status.
>
> How so? Do you mean operating in a shell on a system with no ACL support?
The command-line interface to ACLs is confusing, possibly weak.
>> And NFSv4 is mostly a rumor in my universe; NFSv2 and v3 are what
people
>> actually use.
>
> Really? We''ve deployed NFSv4 here, and other than this ACL/chmod
issue
> it''s
> working great. I think I''d rather design my future technology
based on the
> needs and possibilities of the future, not on the past. From that
> perspective, why should Sun bother to work on NFSv4 at all if nobody uses
> it.
Generally you have to work on things for a while before they get
widespread adoption, especially by outside implementers.  It''s entirely
possible that NFS V4 will be widely used, but from what I read on linux
sysadmin forums, it isn''t yet.
> Again, I''m not advocating removing any current functionality or
depriving
> you of anything you currently have. I''m simply requesting an
additional
> feature set that would be very useful for some deployments. I''m
not really
> sure why people keep arguing about why it would not be good for their
> deployment, and considering such a reason it should not be implemented --
> that seems a bit self-centered.
When a tool is there, people will want to use it.  When using it causes me
endless trouble, I don''t want them to use it.

We''re all arguing for what will work best for us, I think; selfish, but
I
hope in the "sanely selfish" region.
-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On Wed, 3 Mar 2010, David Dyer-Bennet wrote:
> It''s the normal way to do it; not sure where in the Linux world it
arose,
> but I first saw it in some early distribution.  It''s done
automatically by
> "adduser".   In my perception, it''s "best
practice".  So the question is,
> why do you NOT want to do it?
It''s the "historical" way to do it. Best practices change
over time. As
I''ve already indicated, I would get no benefits from such a practice,
and
it would result in 70000 extra unnecessary groups in my environment. It
used to be common practice to leave your smtp servers as open relays, would
you have argued against locking them down because implementing smtp
authentication was too hard for you? It used to be common practice to
access servers via telnet, would you have argued against the deployment of
ssh because you didn''t want to learn how to configure it? Your basic
premise in this argument seems to be that the tools to create a pure-ACL
environment shouldn''t be made available to anyone because you
don''t
understand ACL''s, they''re too hard (for you) to use, and you
would have to
change how you do things.
> I can''t believe in that model. If I buy it, every time I consider
a
> script set or application for use, I have to do extensive testing to
> verify that it works in the model.
And conversely, every time I consider a script or application for my
current deployment, I have to do extensive testing to make sure it
doesn''t
break my ACL''s. It can''t always be about you.
> And I have to deal with users having that problem on their own.  This is
> far, far too expensive to give any serious consideration to.
The option I propose would only be configurable by someone who had
privileges to update zfs filesystem properties. If that''s the sysadmin,
clearly he wants it that way. If end users are delegated that privilege,
they must be deemed competent enough to shoot their own foot.
> The command-line interface to ACLs is confusing, possibly weak.
Matter of perspective. I don''t have much trouble with it, and if I did
I''d
write my own interface (as I''ve done before
http://www.cpan.org/modules/by-authors/id/PHENSON/aclmod-1.1.readme).
> Generally you have to work on things for a while before they get
> widespread adoption, especially by outside implementers.  It''s
entirely
> possible that NFS V4 will be widely used, but from what I read on linux
> sysadmin forums, it isn''t yet.
Somebody has to go first or it''s a chicken and egg problem. And it
seems
reasonable that the people who do go first will run into issues that need
new best practices to be deployed, no? And then it kind of sucks that
people who aren''t even using the technology cry that models
shouldn''t
change while fearfully grasping their buggy whips ;).
> When a tool is there, people will want to use it.  When using it causes
> me endless trouble, I don''t want them to use it.
If it''s your server, you choose whether the option is used. If
it''s not
your server, or the user has been granted permission to manage their own
filesystem, then it seems it''s not really up to you, and I''m
not sure why
you think you should be able to dictate what other people do with their own
environments.
> We''re all arguing for what will work best for us, I think;
selfish, but I
> hope in the "sanely selfish" region.
The difference is I''m arguing for functionality that I need and will be
valuable in my environment. You''re arguing that someone else
shouldn''t be
able to get the functionality they need because you won''t be happy if
it
exists at all, even if no one forces you to use it. It seems that''s an
entirely different grade of selfishness, like a bully who knocks you down
and steals your lunch but just throws it away because he doesn''t like
peanut butter :(. It''s not about getting something you need but just
keeping someone else from having it.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768

On Wed, March 3, 2010 10:23, Paul B. Henson wrote:
> On Wed, 3 Mar 2010, David Dyer-Bennet wrote:
>
>> It''s the normal way to do it; not sure where in the Linux
world it
>> arose,
>> but I first saw it in some early distribution.  It''s done
automatically
>> by
>> "adduser".   In my perception, it''s "best
practice".  So the question
>> is,
>> why do you NOT want to do it?
>
> It''s the "historical" way to do it. Best practices
change over time. As
> I''ve already indicated, I would get no benefits from such a
practice, and
> it would result in 70000 extra unnecessary groups in my environment. It
> used to be common practice to leave your smtp servers as open relays,
> would
> you have argued against locking them down because implementing smtp
> authentication was too hard for you? It used to be common practice to
> access servers via telnet, would you have argued against the deployment of
> ssh because you didn''t want to learn how to configure it? Your
basic
> premise in this argument seems to be that the tools to create a pure-ACL
> environment shouldn''t be made available to anyone because you
don''t
> understand ACL''s, they''re too hard (for you) to use, and
you would have to
> change how you do things.
I don''t think it will work as well for  you as you think it will; I
think
you''ll then find yourself complaining that backup systems
don''t work, and
indexing systems don''t work, and this doesn''t work, and that
doesn''t work,
all because you''ve broken the underlying model.  And I have a definite
fear that it''ll end up impacting me, that "not using it"
won''t be as clear
an option as you think it will.

And I''m pretty sure I''ve said considerably more than is really
necessary,
at this point, so I will try very hard to avoid getting sucked back into
this discussion, at least with just the same old opinions.
-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On Wed, 3 Mar 2010, David Dyer-Bennet wrote:
> I don''t think it will work as well for you as you think it will; I
think
> you''ll then find yourself complaining that backup systems
don''t work, and
> indexing systems don''t work, and this doesn''t work, and
that doesn''t work,
> all because you''ve broken the underlying model.
Thanks for the concern :), but I think I know my potential use cases pretty
well. I don''t know why backups would fail, they shouldn''t be
wandering
around changing permissions. And our backup system supports ZFS ACL''s
anyway. Indexing systems? It''s not a windows box ;). I doubt it would
be
wise to configure this hypothetical option on a root pool, but as far as
I''m concerned, on my user/group data filesystems, this would be
*fixing*
the underlying model (pure-ACL), not breaking it.
> And I have a definite fear that it''ll end up impacting me, that
"not
> using it" won''t be as clear an option as you think it will.
Technology changes; it''s a bad field to be in for the change adverse
:).


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768