May 11, 2005

Drawbacks to using ACLs for Samba

Part of discussion with a superior in Feb, 2004 ---

If you need to enforce very granular security,
I agree that ACLs can be wonderful. The thing
is, I have yet to see a situation at Biomed
that really requires them. Few if any of the
staff here, or elsewhere I suspect, want to
get very fine-grained about who can do what.

One of the definite downsides of ACLs is the
dearth of good tools for managing them in UNIX.
NetWare has Console One, Windows has whatever,
but on FreeBSD Dan had to write a perl script
just to enable me to tweak ACLs for a big set
of directories and files without mucking up
the timestamps of the files in the process.

ACLs are used to grant two or more existing
groups different rights to one directory,
but this can also be accomplished by making
a new group for each new special-purpose dir
(and all its children except as over-ridden).

Maintenance of a dozen or two special-purpose
groups strikes me as easier than maintaining
ACLs for every directory, and yet does about
the same thing from a user perspective. Samba
can automatically handle file and directory
inheritance of ACLs and standard UNIX rights.

One constraint worth noting is that there are
limits to how many users can be in a group and
to how many groups a user can be assigned to.
In the case of FreeBSD 5.2.1, a default is 16
groups per user and something around a hundred
users in a group - it's really the line length
of a user list = 1024. Tweaking this could be
tricky (Thanks, Dan, for all that detail).

Since we have way less than a hundred staff
and no staff member should need more than 16
groups, assuming we don't go crazy with rights,
then those limits should not be a problem here
at Biomed. They may be in a larger population,
though, so I would not call this idea scalable.

I understand that we are not the only ones who
thought ACLs were critical but later found that
they aren't. The relative merits of ACLs have
been debated extensively in online discussions
regarding FreeBSD and probably other platforms.

It seems easiest from a human perspective to keep
the explanation of security relatively simple:


1. Assume that all staff get either no rights or
read-only to various directories off of drive O:.
BIS and Admin, for example, have hidden theirs.

2. All members of a department get full rights
to their directory and its children. Samba can
handle inheritance of rights below directories.

3. A new subdirectory of an existing directory
(and its children) can be granted other rights
simply by making that new dir owned by a more
inclusive or exclusive group, one that might
include, say, FTEs plus dept. student workers.

4. Directories to be shared across departments
can be created in a separate, general-purpose
area independent of departmental directories.


As noted above, UNIX rights may not be terribly
scalable or granular, but my comments pertain
mostly to the departmental (e.g. Biomed) level
rather than enterprise needs. Fifty staff with
uncomplicated security needs don't need ACLs.

If I'm mistaken, please help me see what I have
missed. I do appreciate the thoughtful feedback.

Posted by tapli005 at May 11, 2005 9:43 AM