"Filers" and ACLs - NFS

This is a discussion on "Filers" and ACLs - NFS ; I've been speaking to EMC, NetApp, and RaidZone. EMC has yet to answer, NetApp has given a partial answer, and RaidZone has answered in the negative but they may fix this. The question is which NFS "filers" (ie. a dedicated ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: "Filers" and ACLs

  1. "Filers" and ACLs

    I've been speaking to EMC, NetApp, and RaidZone. EMC has yet to answer,
    NetApp has given a partial answer, and RaidZone has answered in the
    negative but they may fix this.

    The question is which NFS "filers" (ie. a dedicated NFS server, like EMC's
    IP4700 or NS600 and 700, NetApp's FAS line, or RaidZone's GangStor product)
    support the "near POSIX" ACLs long available on Solaris and (more recently)
    Linux?

    If Solaris and Linux (we're a mixed shop, so I do mean "and") supported
    NFSv4, then I'd be asking about ACLs in general. But I don't think either
    of those two operating systems has full NFSv4 support yet.

    So...how can I preserve my use of ACLs but still switch over to a dedicated
    NFS server? Is there another player in this market? Am I out of luck?

    Thanks...

    Andrew


  2. Re: "Filers" and ACLs

    Andrew Gideon wrote in message news:<16670040.juzYthajti@no.to.be.used.news.int.tagonli ne.com>...
    > I've been speaking to EMC, NetApp, and RaidZone. EMC has yet to answer,
    > NetApp has given a partial answer, and RaidZone has answered in the
    > negative but they may fix this.
    >
    > The question is which NFS "filers" (ie. a dedicated NFS server, like EMC's
    > IP4700 or NS600 and 700, NetApp's FAS line, or RaidZone's GangStor product)
    > support the "near POSIX" ACLs long available on Solaris and (more recently)
    > Linux?


    NetApp's FAS filers do not support POSIX ACLs.
    You'd have to set NT ACLs via CIFS to get ACL features from FAS filers.

  3. Re: "Filers" and ACLs

    On Fri, 23 Apr 2004 17:14:40 -0400, Andrew Gideon
    wrote:

    >I've been speaking to EMC, NetApp, and RaidZone. EMC has yet to answer,
    >NetApp has given a partial answer, and RaidZone has answered in the
    >negative but they may fix this.
    >
    >The question is which NFS "filers" (ie. a dedicated NFS server, like EMC's
    >IP4700 or NS600 and 700, NetApp's FAS line, or RaidZone's GangStor product)
    >support the "near POSIX" ACLs long available on Solaris and (more recently)
    >Linux?
    >
    >If Solaris and Linux (we're a mixed shop, so I do mean "and") supported
    >NFSv4, then I'd be asking about ACLs in general. But I don't think either
    >of those two operating systems has full NFSv4 support yet.
    >
    >So...how can I preserve my use of ACLs but still switch over to a dedicated
    >NFS server? Is there another player in this market? Am I out of luck?
    >
    >Thanks...
    >
    > Andrew


    Well I'm very interested in what others have to say on this. I
    thought there were no ACL capabilities in NFSv3 and below, regardless
    of the serving OS. It was a function of the NFS protocol that
    restricted this I thought.

    I understand NFSv4 to fix this for the most part but as you point out
    not all OS's support this fully. Although I thought Solaris was one
    of them.

    ~F

  4. Re: "Filers" and ACLs

    Faeandar wrote:


    > Well I'm very interested in what others have to say on this. I
    > thought there were no ACL capabilities in NFSv3 and below, regardless
    > of the serving OS. It was a function of the NFS protocol that
    > restricted this I thought.


    I cannot speak to details or mechanism, but Solaris has provided ACLs in
    ("via"? "through"? "with"?) NFS for quite some time. More recently,
    Linux has added support for these ACLs (ie. Redhat Enterprise 3 ships with
    this).

    This is not NFSv4. In fact, some of what I've read indicates that there are
    some interesting (read: annoying {8^) inconsistencies between this ACL
    mechanism (which is not standardized, but which was - I believe - going
    through the POSIX process at one point) and the ACLs to be in NFSv4.

    > I understand NFSv4 to fix this for the most part but as you point out
    > not all OS's support this fully. Although I thought Solaris was one
    > of them.


    Both EMC and NetApp have told me that, despite their support for NFSv4, they
    do not support ACLs in NFSv4. I didn't realize that this was possible, but
    perhaps ACLs are an optional feature.

    Because NFSv4 doesn't help me (ie. I don't get ACL support by exploiting the
    NFSv4 support in NetApp or EMC systems), I've not looked into the support
    available on either Solaris or Linux for NFSv4.

    RaidZone, however, is willing to support the ACLs that Redhat (and therefore
    Solaris) is providing. This *does* suit my needs. So that appears to be
    my direction.

    I have to admit that this entire investigation has left me amazed. We've
    been a Solaris shop since before Solaris , and ACLs were a terrific
    feature we exploited early on. That cannot be unusual, so I was quite
    surprised to see so little support for ACLs in the marketplace. Especially
    given that both vendors support ACLs via SMB, I don't understand the lag.

    Someone at EMC told me that NFSv4 ACLs were not in the "roadmap" for this
    year. I've not yet received a definitive answer like that from NetApp, so
    it is *possible* (and I can still hope {8^) that this is just around the
    corner for them.

    - Andrew


  5. Re: "Filers" and ACLs

    Faeandar wrote in message news:<917r8051qfk0sqn3pp6dp0aav1j68s32ea@4ax.com>...
    > On Fri, 23 Apr 2004 17:14:40 -0400, Andrew Gideon
    > wrote:
    >
    > >I've been speaking to EMC, NetApp, and RaidZone. EMC has yet to answer,
    > >NetApp has given a partial answer, and RaidZone has answered in the
    > >negative but they may fix this.
    > >
    > >The question is which NFS "filers" (ie. a dedicated NFS server, like EMC's
    > >IP4700 or NS600 and 700, NetApp's FAS line, or RaidZone's GangStor product)
    > >support the "near POSIX" ACLs long available on Solaris and (more recently)
    > >Linux?
    > >
    > >If Solaris and Linux (we're a mixed shop, so I do mean "and") supported
    > >NFSv4, then I'd be asking about ACLs in general. But I don't think either
    > >of those two operating systems has full NFSv4 support yet.
    > >
    > >So...how can I preserve my use of ACLs but still switch over to a dedicated
    > >NFS server? Is there another player in this market? Am I out of luck?
    > >
    > >Thanks...
    > >
    > > Andrew

    >
    > Well I'm very interested in what others have to say on this. I
    > thought there were no ACL capabilities in NFSv3 and below, regardless
    > of the serving OS. It was a function of the NFS protocol that
    > restricted this I thought.


    Read page 253 of my book, 4th paragraph.

  6. Re: "Filers" and ACLs

    On 27 Apr 2004 09:59:00 -0700, spamisevi1@yahoo.com (Mike Eisler)
    wrote:

    >Faeandar wrote in message news:<917r8051qfk0sqn3pp6dp0aav1j68s32ea@4ax.com>...
    >> On Fri, 23 Apr 2004 17:14:40 -0400, Andrew Gideon
    >> wrote:
    >>
    >> >I've been speaking to EMC, NetApp, and RaidZone. EMC has yet to answer,
    >> >NetApp has given a partial answer, and RaidZone has answered in the
    >> >negative but they may fix this.
    >> >
    >> >The question is which NFS "filers" (ie. a dedicated NFS server, like EMC's
    >> >IP4700 or NS600 and 700, NetApp's FAS line, or RaidZone's GangStor product)
    >> >support the "near POSIX" ACLs long available on Solaris and (more recently)
    >> >Linux?
    >> >
    >> >If Solaris and Linux (we're a mixed shop, so I do mean "and") supported
    >> >NFSv4, then I'd be asking about ACLs in general. But I don't think either
    >> >of those two operating systems has full NFSv4 support yet.
    >> >
    >> >So...how can I preserve my use of ACLs but still switch over to a dedicated
    >> >NFS server? Is there another player in this market? Am I out of luck?
    >> >
    >> >Thanks...
    >> >
    >> > Andrew

    >>
    >> Well I'm very interested in what others have to say on this. I
    >> thought there were no ACL capabilities in NFSv3 and below, regardless
    >> of the serving OS. It was a function of the NFS protocol that
    >> restricted this I thought.

    >
    >Read page 253 of my book, 4th paragraph.


    ok, I haven't read that far yet so I'm just going by the paragraph and
    those around it. So this sideband protocol only works on Solaris 2.5
    and up? And these ACL settings work just like they would on a local
    file system?

    Sheesh, this is what I get for taking people at their word and
    apparent knowledge. For 3 years now I thought ACL's were not an
    option in NFS, I never even tried. Shame on me.

    ~F


  7. Re: "Filers" and ACLs

    Faeandar wrote:


    > ok, I haven't read that far yet so I'm just going by the paragraph and
    > those around it.


    Is this a good book for me? I'm not interested (at the moment, anyway {8^)
    in coding an NFS client or server, but a basic understanding of protocol
    details would probably be a useful tool in managing my network.

    > So this sideband protocol only works on Solaris 2.5
    > and up? And these ACL settings work just like they would on a local
    > file system?


    On Solaris, since 2.6 (2.5 has some issues), I've seen no distinction
    between ACLs on a local filesystem and via NFS. I've not done heavy
    testing, but the little I've done indicates compatibility between the
    current RH ACLs and Solaris ACLs.

    The only problem that's arisen from time to time is that much software
    checks the file's "mode", and ignores the ACLs. Some of these are *basic*,
    like the -r test and its friends in Perl.

    - Andrew


  8. Re: "Filers" and ACLs

    Andrew Gideon wrote in message news:<1796895.6BOBjBXYsW@no.to.be.used.news.int.tagonlin e.com>...
    > Both EMC and NetApp have told me that, despite their support for NFSv4, they
    > do not support ACLs in NFSv4. I didn't realize that this was possible, but


    So if NetApp and EMC, which sell only servers, each sold an NFSv4 server with
    ACLs, which NFSv4 client would interoperate it with it?

    Anyway, the chatter on the NFSv4 working group alias makes it clear
    that NFSv4 ACL support is in the plans of EMC and NetApp.

    > perhaps ACLs are an optional feature.


    ACLs are in fact a RECOMMENDED attribute in the NFSv4 specification.
    RECOMMENDED means that an implementation should support a feature, unless
    there is a compelling reason to not do so. The compelling reason for
    an NFSv4 server implementor is no clients to use it. I don't know
    a compelling reason for the client makers, other than it is more work,
    and they'll probably get to it eventually.

    > I have to admit that this entire investigation has left me amazed. We've
    > been a Solaris shop since before Solaris , and ACLs were a terrific
    > feature we exploited early on. That cannot be unusual, so I was quite
    > surprised to see so little support for ACLs in the marketplace. Especially


    You're a rare customer. The POSIX ACL stuff has, in my informed opinion,
    been a failure among customers. That more customers ask how to increase
    the number of supplemental group ids than about ACLs says it all.

    IBM, Sun, HP (ISH) etc. each have sideband protocols for ACLs over
    NFS, and none have chosen to publish or license their protocols.

    If the market demanded ISH ACLs the NAS industry would meet the
    demand.

    > given that both vendors support ACLs via SMB, I don't understand the lag.


    ACLs via SMB represent a defacto standard. There are 100s of millions of
    SMB clients out there that support them, so any NAS vendor that claims CIFS
    support really needs to have SMB ACL support. Whereas, of the
    NFSv4 clients out there today
    (counting Hummingbird, Solaris Express, Linux 2.6, in order of release),
    none of them have NFSv4 ACL support.

  9. Re: "Filers" and ACLs

    Mike Eisler wrote:

    > Andrew Gideon wrote in message
    > news:<1796895.6BOBjBXYsW@no.to.be.used.news.int.tagonlin e.com>...
    >> Both EMC and NetApp have told me that, despite their support for NFSv4,
    >> they
    >> do not support ACLs in NFSv4. I didn't realize that this was possible,
    >> but

    >
    > So if NetApp and EMC, which sell only servers, each sold an NFSv4 server
    > with ACLs, which NFSv4 client would interoperate it with it?


    I don't know. I've not looked at NFSv4 clients since the NFSv4 servers
    don't help me.

    [...]
    > ACLs are in fact a RECOMMENDED attribute in the NFSv4 specification.


    Ah.

    > RECOMMENDED means that an implementation should support a feature, unless
    > there is a compelling reason to not do so. The compelling reason for
    > an NFSv4 server implementor is no clients to use it. I don't know
    > a compelling reason for the client makers, other than it is more work,
    > and they'll probably get to it eventually.


    A compelling reason for the clients could be that no servers support it.
    That's as reasonable as the server builders' logic...but of course that way
    leads to a starvation problem.

    >
    >> I have to admit that this entire investigation has left me amazed. We've
    >> been a Solaris shop since before Solaris , and ACLs were a terrific
    >> feature we exploited early on. That cannot be unusual, so I was quite
    >> surprised to see so little support for ACLs in the marketplace.
    >> Especially

    >
    > You're a rare customer.


    I've come to suspect this, but that just shifts my surprise from one concept
    to another. ACLs are so obviously helpful...

    How else can I have three different sets of users with three different sets
    of rights on a resource? Am I missing something? Have years of using ACLs
    turned my chmod() brain to mush?

    [Three is pretty much typical: all, read-only, and none.]

    > The POSIX ACL stuff has, in my informed opinion,
    > been a failure among customers. That more customers ask how to increase
    > the number of supplemental group ids than about ACLs says it all.


    I'm afraid that it doesn't say anything to me. Would you explain,
    please?

    >
    > IBM, Sun, HP (ISH) etc. each have sideband protocols for ACLs over
    > NFS, and none have chosen to publish or license their protocols.


    Interesting. So are Linux and Solaris ACLs cooperating?

    [...]
    > Whereas, of the
    > NFSv4 clients out there today
    > (counting Hummingbird, Solaris Express, Linux 2.6, in order of release),
    > none of them have NFSv4 ACL support.


    I wonder what their "compelling reason" was.

    - Andrew



  10. Re: "Filers" and ACLs

    Andrew Gideon wrote:

    > Interesting. So are Linux and Solaris ACLs cooperating?


    Wups...the question is *How* are Linux and Solaris ACLs cooperating. More
    specifically, how are the NFS servers and clients cooperating in their
    sharing of ACLs?

    - Andrew


  11. Re: "Filers" and ACLs

    Andrew Gideon wrote in message news:<1212799.yRfFIcObBr@no.to.be.used.news.int.tagonlin e.com>...
    > > ok, I haven't read that far yet so I'm just going by the paragraph and
    > > those around it.

    >
    > Is this a good book for me? I'm not interested (at the moment, anyway {8^)
    > in coding an NFS client or server, but a basic understanding of protocol
    > details would probably be a useful tool in managing my network.


    My book discusses the "parts" that make up NFS. Protocol details
    are discussed in brent Callaghan's book. There isn't a book of that strikes a
    middle ground in detail that I know of. I believe you might find info
    useful to a system/network manager such as yourself.

    > > So this sideband protocol only works on Solaris 2.5
    > > and up? And these ACL settings work just like they would on a local
    > > file system?

    >
    > On Solaris, since 2.6 (2.5 has some issues), I've seen no distinction
    > between ACLs on a local filesystem and via NFS. I've not done heavy


    That should be the case.

    > testing, but the little I've done indicates compatibility between the
    > current RH ACLs and Solaris ACLs.
    >
    > The only problem that's arisen from time to time is that much software
    > checks the file's "mode", and ignores the ACLs. Some of these are *basic*,
    > like the -r test and its friends in Perl.


    Wow. Either perl doesn't use access(), or it could be the Linux
    access() system call doesn't generate an over the wire NFSv3 ACCESS.

    -mre

    Co-author Managing NFS and NIS, Second Edition.

    http://www.oreilly.com/catalog/nfs2/index.html

  12. Re: "Filers" and ACLs

    On Fri, 23 Apr 2004 17:14:40 -0400, Andrew Gideon
    wrote:

    >I've been speaking to EMC, NetApp, and RaidZone. EMC has yet to answer,
    >NetApp has given a partial answer, and RaidZone has answered in the
    >negative but they may fix this.
    >
    >The question is which NFS "filers" (ie. a dedicated NFS server, like EMC's
    >IP4700 or NS600 and 700, NetApp's FAS line, or RaidZone's GangStor product)
    >support the "near POSIX" ACLs long available on Solaris and (more recently)
    >Linux?
    >
    >If Solaris and Linux (we're a mixed shop, so I do mean "and") supported
    >NFSv4, then I'd be asking about ACLs in general. But I don't think either
    >of those two operating systems has full NFSv4 support yet.
    >
    >So...how can I preserve my use of ACLs but still switch over to a dedicated
    >NFS server? Is there another player in this market? Am I out of luck?
    >
    >Thanks...
    >
    > Andrew


    Ok, so here's my understanding so far.

    1) ACL's over nfs in Solaris are Solaris *only*. Meaning you can only
    have Solaris clients mounting Solaris NFS servers. If you do that
    then you can use standard ACL's. Go outside of that and it breaks.
    Other vendors may work the same.

    2) NetApp will be supporting ACL's over NFSv4. *But* it's not a
    priority right now since no clients support it.

    3) ALC's are great but most Unix people don't use them or even know
    what they are. We use AFS and ACL's are second nature, but only in
    AFS space. Unix has no ACL's set anywhere.

    4) More and more customers are wanting greater access control. Those
    who understand Unix or have used AFS ask for ACL's. Those who do not
    ask for more groups.

    Not really questions, just wanted to share.

    ~F

  13. Re: "Filers" and ACLs

    Faeandar wrote:

    > 1) ACL's over nfs in Solaris are Solaris *only*. Meaning you can only
    > have Solaris clients mounting Solaris NFS servers. If you do that
    > then you can use standard ACL's. Go outside of that and it breaks.
    > Other vendors may work the same.


    Solaris and Redhat Enterprise 3 understand one another's ACLs via NFS. I
    cannot speak to other products.

    > 2) NetApp will be supporting ACL's over NFSv4. *But* it's not a
    > priority right now since no clients support it.


    They've yet to tell me that, but I expect you're right.

    > 4) More and more customers are wanting greater access control. Those
    > who understand Unix or have used AFS ask for ACL's. Those who do not
    > ask for more groups.


    Someone else mentioned this relationship, but I don't understand how more
    groups can replace ACLs. My basic problem - why I've been a happy user of
    Solaris ACLs for so long - is that I typically have a collection of users
    that need full access, another collection that get r/o access, and everyone
    else should get no access.

    How does the standard UNIX mechanism with unlimited groups help address
    this? Am I missing it from years of lazy ACL use?

    - Andrew


  14. Re: "Filers" and ACLs

    On Thu, 29 Apr 2004 13:38:06 -0400, Andrew Gideon
    wrote:

    >Faeandar wrote:
    >
    >> 1) ACL's over nfs in Solaris are Solaris *only*. Meaning you can only
    >> have Solaris clients mounting Solaris NFS servers. If you do that
    >> then you can use standard ACL's. Go outside of that and it breaks.
    >> Other vendors may work the same.

    >
    >Solaris and Redhat Enterprise 3 understand one another's ACLs via NFS. I
    >cannot speak to other products.


    RedHat knows who the Unix King is and got in bed with them. Good
    move.

    >
    >> 2) NetApp will be supporting ACL's over NFSv4. *But* it's not a
    >> priority right now since no clients support it.

    >
    >They've yet to tell me that, but I expect you're right.


    They told me. It's confirmed.

    >
    >> 4) More and more customers are wanting greater access control. Those
    >> who understand Unix or have used AFS ask for ACL's. Those who do not
    >> ask for more groups.

    >
    >Someone else mentioned this relationship, but I don't understand how more
    >groups can replace ACLs. My basic problem - why I've been a happy user of
    >Solaris ACLs for so long - is that I typically have a collection of users
    >that need full access, another collection that get r/o access, and everyone
    >else should get no access.
    >
    >How does the standard UNIX mechanism with unlimited groups help address
    >this? Am I missing it from years of lazy ACL use?


    Same as NTFS. Make a global group and put users in it, give that
    group the permisisons needed.

    ie. DATA_eng-WRITE
    DATA_eng-READ

    2 groups, each with different permissions, each containing different
    users. Same concept for Unix. Of course ACL's work too.
    now that I think about this is what ACL's are in NTFS, multiple
    objects with unique permissions applied to the same resource.

    ~F

  15. Re: "Filers" and ACLs

    Andrew Gideon wrote in message news:<3703269.3P7RsMQYNK@no.to.be.used.news.int.tagonlin e.com>...
    > Mike Eisler wrote:
    > A compelling reason for the clients could be that no servers support it.
    > That's as reasonable as the server builders' logic...but of course that way
    > leads to a starvation problem.


    Hummingbird, Sun, Linux, etc. offer both NFS
    clients and servers. Self-starvation? :-)

    > >> I have to admit that this entire investigation has left me amazed. We've
    > >> been a Solaris shop since before Solaris , and ACLs were a terrific
    > >> feature we exploited early on. That cannot be unusual, so I was quite
    > >> surprised to see so little support for ACLs in the marketplace.
    > >> Especially

    > >
    > > You're a rare customer.

    >
    > I've come to suspect this, but that just shifts my surprise from one concept
    > to another. ACLs are so obviously helpful...
    >
    > How else can I have three different sets of users with three different sets
    > of rights on a resource? Am I missing something? Have years of using ACLs
    > turned my chmod() brain to mush?


    My problem with ACLs, especially POSIX ACLs, is that I have to remember
    an arcane sequence of stuff, and remember to apply to everything I
    want to have the same access controls. What would have been nice is
    if there was an /etc/acls file (and an acl table in NIS, LDAP, etc.)
    that had a string names for distinct ACLs. Then they'd be far easier
    for users to deal with.

    Even better would be if instead of the actual ACL being stored in
    every inode, a shorthand for the ACL, either a 32 bit number in the
    acl database, or the actual acl string name. Then when the ACL was
    changed, one wouldn't have to to recursively change everything in
    a tree of files and directories.

    > [Three is pretty much typical: all, read-only, and none.]
    >
    > > The POSIX ACL stuff has, in my informed opinion,
    > > been a failure among customers. That more customers ask how to increase
    > > the number of supplemental group ids than about ACLs says it all.

    >
    > I'm afraid that it doesn't say anything to me. Would you explain,
    > please?


    Shops that rely heavily on group based access control comparmentalize
    file-based data so that group A gets access to data set I, and group
    B gets access to data set II, etc. The group owners of
    data sets I and II are respectively set to group A and group B.
    Some people need access to more than one data set, so the groups database
    is edited to put people in multiple groups. Beyond 16 groups, and
    NFS over AUTH_SYS doesn't work. ACLs are one way around this ...
    grant access to more users by adding them to ACL for a file (each with
    same permission). Nice, except that it is not as simple to
    manage as more groups in the groups database. Hence my comment about
    the need for an acls database.

    Clearly ACLs can do things that groups cannot. Not eveyone needs
    that complexity, at least not most of the time.

    > > IBM, Sun, HP (ISH) etc. each have sideband protocols for ACLs over
    > > NFS, and none have chosen to publish or license their protocols.

    >
    > Interesting. So are Linux and Solaris ACLs cooperating?


    Apparently. Since the Solaris nfs_acl.x file ships with Solaris,
    it would be easy enough to code the protocol, assuming the
    local file system inode changes were done. Whether that's an intellectual
    property infrinement or not is anyones guess. I reckon it depends on how
    it was done. But IANAL.

    > [...]
    > > Whereas, of the
    > > NFSv4 clients out there today
    > > (counting Hummingbird, Solaris Express, Linux 2.6, in order of release),
    > > none of them have NFSv4 ACL support.

    >
    > I wonder what their "compelling reason" was.


    Not a higher priority than getting the as much of the mandatory and
    other recommended features done as possible for a first release.
    Delegations for instance should provide awesome performance wins for
    some workloads. Also, mapping the POSIX ACL api to the NFSv4 ACL
    scheme is proving challenging.

  16. Re: "Filers" and ACLs

    Mike Eisler wrote:

    > Andrew Gideon wrote in message
    > news:<3703269.3P7RsMQYNK@no.to.be.used.news.int.tagonlin e.com>...
    >> Mike Eisler wrote:
    >> A compelling reason for the clients could be that no servers support it.
    >> That's as reasonable as the server builders' logic...but of course that
    >> way leads to a starvation problem.

    >
    > Hummingbird, Sun, Linux, etc. offer both NFS
    > clients and servers. Self-starvation? :-)


    That's an excellent point. It gets "worse" in the case of SUN, in
    that they already do support the "near POSIX" ACLs. But as you note below
    (and as I've read recently), the mapping of "near POSIX" ACLs to NFSv4 is
    proving less than trivial.


    [...]
    >> How else can I have three different sets of users with three different
    >> sets
    >> of rights on a resource? Am I missing something? Have years of using
    >> ACLs turned my chmod() brain to mush?

    >
    > My problem with ACLs, especially POSIX ACLs, is that I have to remember
    > an arcane sequence of stuff, and remember to apply to everything I
    > want to have the same access controls. What would have been nice is
    > if there was an /etc/acls file (and an acl table in NIS, LDAP, etc.)
    > that had a string names for distinct ACLs. Then they'd be far easier
    > for users to deal with.
    >
    > Even better would be if instead of the actual ACL being stored in
    > every inode, a shorthand for the ACL, either a 32 bit number in the
    > acl database, or the actual acl string name. Then when the ACL was
    > changed, one wouldn't have to to recursively change everything in
    > a tree of files and directories.


    I like the idea of ACL "macros" you're presenting. For myself, I've been
    doing this long enough that 'find' is second-nature. But this would make
    ACL features far more accessible, I agree.

    But I'm still left wondering if there's a way to implement my "three group"
    scenario using basic chmod().

    >> [Three is pretty much typical: all, read-only, and none.]
    >>
    >> > The POSIX ACL stuff has, in my informed opinion,
    >> > been a failure among customers. That more customers ask how to increase
    >> > the number of supplemental group ids than about ACLs says it all.

    >>
    >> I'm afraid that it doesn't say anything to me. Would you
    >> explain, please?

    >
    > Shops that rely heavily on group based access control comparmentalize
    > file-based data so that group A gets access to data set I, and group
    > B gets access to data set II, etc. The group owners of
    > data sets I and II are respectively set to group A and group B.
    > Some people need access to more than one data set, so the groups database
    > is edited to put people in multiple groups. Beyond 16 groups, and
    > NFS over AUTH_SYS doesn't work.


    Ah! I'd never noticed this. That must lead to a lot of factoring, I
    imagine.

    > ACLs are one way around this ...
    > grant access to more users by adding them to ACL for a file (each with
    > same permission). Nice, except that it is not as simple to
    > manage as more groups in the groups database. Hence my comment about
    > the need for an acls database.
    >
    > Clearly ACLs can do things that groups cannot. Not eveyone needs
    > that complexity, at least not most of the time.


    My problem is the need to have three different groups (one of which can be
    "other") with three different levels of access. I'm surprised that this is
    so unusual.

    [...]

    >> I wonder what their "compelling reason" was.

    >
    > Not a higher priority than getting the as much of the mandatory and
    > other recommended features done as possible for a first release.
    > Delegations for instance should provide awesome performance wins for
    > some workloads. Also, mapping the POSIX ACL api to the NFSv4 ACL
    > scheme is proving challenging.


    Delegations would be fantastic for my environment too. At least it's that
    much like others'.

    - Andrew


  17. Re: "Filers" and ACLs

    Faeandar wrote:

    > RedHat knows who the Unix King is and got in bed with them. Good
    > move.


    Well, they didn't produce the patch, but I agree with you.

    [...]
    >>Someone else mentioned this relationship, but I don't understand how more
    >>groups can replace ACLs. My basic problem - why I've been a happy user of
    >>Solaris ACLs for so long - is that I typically have a collection of users
    >>that need full access, another collection that get r/o access, and
    >>everyone else should get no access.
    >>
    >>How does the standard UNIX mechanism with unlimited groups help address
    >>this? Am I missing it from years of lazy ACL use?

    >
    > Same as NTFS. Make a global group and put users in it, give that
    > group the permisisons needed.
    >
    > ie. DATA_eng-WRITE
    > DATA_eng-READ
    >
    > 2 groups, each with different permissions, each containing different
    > users. Same concept for Unix.


    I'm sorry, but I'm missing how this would work in UNIX (sans ACLs). I can
    see building the "read" group and the "read-write" group easily enough.
    But how can I grant those two groups the proper rights on a file?

    Recall that I need a third group (which can be "other") to have no rights.

    - Andrew


  18. Re: "Filers" and ACLs

    On Fri, 30 Apr 2004 09:56:22 -0400, Andrew Gideon
    wrote:

    >Faeandar wrote:
    >
    >> RedHat knows who the Unix King is and got in bed with them. Good
    >> move.

    >
    >Well, they didn't produce the patch, but I agree with you.
    >
    >[...]
    >>>Someone else mentioned this relationship, but I don't understand how more
    >>>groups can replace ACLs. My basic problem - why I've been a happy user of
    >>>Solaris ACLs for so long - is that I typically have a collection of users
    >>>that need full access, another collection that get r/o access, and
    >>>everyone else should get no access.
    >>>
    >>>How does the standard UNIX mechanism with unlimited groups help address
    >>>this? Am I missing it from years of lazy ACL use?

    >>
    >> Same as NTFS. Make a global group and put users in it, give that
    >> group the permisisons needed.
    >>
    >> ie. DATA_eng-WRITE
    >> DATA_eng-READ
    >>
    >> 2 groups, each with different permissions, each containing different
    >> users. Same concept for Unix.

    >
    >I'm sorry, but I'm missing how this would work in UNIX (sans ACLs). I can
    >see building the "read" group and the "read-write" group easily enough.
    >But how can I grant those two groups the proper rights on a file?
    >
    >Recall that I need a third group (which can be "other") to have no rights.
    >
    > - Andrew


    I think this is the point that Mike was making, most people are asking
    for more group access ACL's which is essentially what NTFS does. Unix
    does not but it has the ACL's you're used to. I was just trying to
    clarify what I thought Mike was pointing out.

    Maybe this is clear as mud now?

    ~F

  19. Re: "Filers" and ACLs

    Andrew Gideon wrote in message news:<1203376.W52n7XP6Tp@no.to.be.used.news.int.tagonlin e.com>...
    > Faeandar wrote:
    >
    > >
    > > I think this is the point that Mike was making, most people are asking
    > > for more group access ACL's which is essentially what NTFS does. Unix


    No. My point was that people want more than 16 groups because
    they want to allow different people to access multiple sets, each
    with a different group owner.

    ACLs would allow one to set arbitrary lists of people who are allowed
    to access a file. If the permission bits are set to the same as
    the group access permission bits, then this is functionally
    equivalent to granting more than 16 groups.

    That ACLs can do much more is interesting, but that was not my point.

    > > does not but it has the ACL's you're used to. I was just trying to
    > > clarify what I thought Mike was pointing out.
    > >
    > > Maybe this is clear as mud now?

    >
    > I'm not being very clear, I suppose. At this point, my primary question is
    > "how can people not be exploiting ACLs". A secondary question is how
    > having a larger number of groups helps people avoid exploiting ACLs.


    See above, and one of other posts in this thread.

    >
    > My basic problem - the three group problem I've described before - just
    > cannot be that unusual! But I cannot see how to solve this w/o ACLs. This
    > could very well be the result of years of softening my brain with ACLs,
    > which is why I'm asking: is there a way to solve this w/o ACLs?


    It cannot be solved without ACLs. Your three groups each have
    different permission bits.

+ Reply to Thread