[mdlug] Fw: am I for real - ACLs difficult to administer

[Robert Meier]

Dean,

Thank you for the situation description.

> This was the situation:
> HR is 2 people, who needed r/w access to a bunch of files.
> A boss, and a worker.  This was non-negotiable.
> The "executive" group of 14 people needed read-only access to the files.  
> And "Everyone else" had to be "no access".
> The server was Solaris.

> Another scenario that came up:
> [Designers] needed r/w access to CAD files.
> Engineers needed read-only.
> All the sales and marketing people
> they wanted to keep out under all circumstances.    

This situation is easily handled with permissions (sic. ugo).

Among the real world uses, look at how other file(?) servers are
configured, such as web pages and ftp storage.

<HINT>
Though variations abound, the generic approach is
  o Create "office"s (i.e. ficticious users) to own the files/directories.
    (e.g. www, wwwrun, ftp, ftpuser)
  o Create "group"s (i.e. user set identifiers)
    to receive/be-denied permissions in parallel.
    (e.g. www, ftp)
  o A file owned by www.www with mode '-rw-r-----' in
    a directory owned by root.wheel with mode '-rw-rwsr--'
    grants to anyone in group wheel (e.g. webmaster) read/write access,
    grants to anyone in group www (e.g. website users) read access,
    denies access to anyone else.
  o ftp installations often use the same arrangement.
  o A file hardlinked between the ftp and web directories,
    grants/denies permission without needing to worry about the overlap.
</HINT>

See ln(1), chmod(1) for details.



Does anyone have handy a tutorial example,
showing two overlapping user groups and file sets,
that need r/w, r/o, and n/a to match his situation?

  

> But the actual server was a "network appliance"
> running some kind of stripped down unix/linux/bsd kernel
> and doing nothing but file serving.
> It was exported out via the Solaris box.     

I suspect your problem is probably related more to the
limitations of your identification of network configuration than
network or server capabilities.

Can you elaborate on "network appliance" "some kind of"
"unix/linux/bsd" "exported out via", especially with regards
to, the authentication and file transfer protocols, used and available.

> In both cases, so far as I could tell, ugo was not good enough.   
> Solaris supported acls, but the netapp didn't.
> Plus everything went out to the windows users via samba.
> Ultimately, it was the version of nfs,
> I learned, being used on the netapp, that didn't support ACLs.   

I understand from the above, that you decided on ACLs before
you identified the situation, and afterwards discovered that
ACLs differ from permissions, tested Solaris support,
test netapp support, samba support, and nfs support.

<IIRC>
Both ACLs and permissions map pathname, user, and access type
to a grant/deny result.
As a monolithic table would grow quadratically with users and pathnames,
practical consideration splits the problem into two tables,
that are joined for lookup.
One table uses pathname in its key.
The other table uses user in its key.
Both tables share key components used to reduce the joined table search
(via a lookaside table).
Permissions reduce the joined table by a lookaside table of
complex "groups" keyed by user, decached by simple mode keyed by pathname.
ACLs reduce the joined table by a lookaside table of
complex "roles" keyed by pathname,
decached by simple access controls keyed by user.
</IIRC>

<IMHO>
The simplicity of mode attached to numerous pathnames makes permissions
more easily managed as the complexity of pathnames grows relative
to the complexity of user distinctions.
The simplicity of access controls attached to numerous users makes
ACLs more easily managed as the complexity of user distinctions grows
relative to the complexity of pathnames.
In my experience, the number of users and and user categories has
been small (<100) compared to the number of pathnames (>1M),
so permissions have been easier.
</IMHO>

I suggest that you look at how to grant/deny access using permissions
on the file server (in like fashion to common web and ftp server practice),
and then look at how to convey user identification (or permissions and group
membership though probably more difficult), across your network.

Hopefully helpful,
-- 
Bob

  "The gulls who scorn perfection for the sake of travel,
      go nowehere slowly.
   The gulls who scorn travel for the sake of perfection,
      go anywhere instantly."
	-- Chang, Jonathan Livingston Seagull by Richard