subject:"Re\: \[zfs\-discuss\] Who is using ZFS ACL's in production\?"

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
every...@. 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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-02 Thread Nicolas Williams

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@/gr...@?) 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 ATT 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
-- 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?


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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-02 Thread Kjetil Torgrim Homme

Paul B. Henson hen...@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
 every...@.  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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-02 Thread Nicolas Williams

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

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-02 Thread Fredrich Maney

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 hen...@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  |  hen...@csupomona.edu
 California State Polytechnic University  |  Pomona CA 91768
 ___
 zfs-discuss mailing list
 zfs-discuss@opensolaris.org
 http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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@/gr...@?) 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

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-02 Thread Kjetil Torgrim Homme

Paul B. Henson hen...@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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-01 Thread Miles Nordin

 pbh == Paul B Henson hen...@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.


pgpO95e3iSCOJ.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-01 Thread Nicolas Williams

On Fri, Feb 26, 2010 at 03:00:29PM -0500, Miles Nordin wrote:
  nw == Nicolas Williams nicolas.willi...@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
-- 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-01 Thread Miles Nordin

 dd == David Dyer-Bennet d...@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.


pgpYqXMNictoq.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-01 Thread Bill Sommerfeld


On 03/01/10 13:50, Miles Nordin wrote:

dd == David Dyer-Bennetd...@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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-01 Thread David Dyer-Bennet


On Mon, March 1, 2010 15:50, Miles Nordin wrote:
 dd == David Dyer-Bennet d...@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, d...@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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-01 Thread Jeffrey Hutzelman

--On Monday, March 01, 2010 03:21:42 PM -0600 Nicolas Williams 
nicolas.willi...@sun.com wrote:



On Fri, Feb 26, 2010 at 03:00:29PM -0500, Miles Nordin wrote:

 nw == Nicolas Williams nicolas.willi...@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.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-01 Thread Paul B. Henson

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-03-01 Thread Paul B. Henson

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-28 Thread Kjetil Torgrim Homme

Paul B. Henson hen...@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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Ian Collins


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.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Darren J Moffat


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

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Oscar del Rio


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

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Thomas Burgess

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 hen...@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  |  hen...@csupomona.edu
 California State Polytechnic University  |  Pomona CA 91768
 ___
 zfs-discuss mailing list
 zfs-discuss@opensolaris.org
 http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Nicolas Williams

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

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Bill Sommerfeld


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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Miles Nordin

 nw == Nicolas Williams nicolas.willi...@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.


pgpap6gwJDM79.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?


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, d...@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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Nicolas Williams

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

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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, 01) // turn off sgid bit
chmod(foo, 014000) // turn on suid bit
chmod(foo, 01) // 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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Nicolas Williams

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

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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 | hen...@csupomona.edu
California State Polytechnic University | Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

2010-02-26 Thread Bill Sommerfeld


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

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?


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, d...@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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?


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, d...@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

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?


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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?

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  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Who is using ZFS ACL's in production?