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.

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

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

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.

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

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

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.

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

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

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

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

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

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

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.

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

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

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

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.