(really stupid) Zone file question

Sun May 1 04:52:00 EDT 2005

On Sat, Apr 30, 2005 at 05:45:30PM -0400, Bill McGonigle wrote:
> On Apr 30, 2005, at 06:09, Fred wrote:
> 
> >I can't be the only one with this need.
> 
> Too often we just accept the status quo without challenging (with 
> patches, of course).   

Sometimes the staus quo really is better than proposed "solutions"...  

> If anyone hasn't read the ArsTechnica review of Mac OS X 10.4 
> <http://arstechnica.com/reviews/os/macosx-10.4.ars/1> I recommend doing 
> so, especially for this crowd the stuff they've done to fix historical 
> Unix deficiencies.

I haven't finished the article yet, but I've read enough to be able to
provide an example of the above (and point out factual errors in the
article).

Premise: ACLs are needed, because (in the words of the article), "it's
still not hard to construct scenarios in which they do not offer
enough control."

Arguments can be made, but I'll go ahead and strongly disagree with
that statement.  Don't worry, I'll explain why.

The article provides an example scenario to "support" this premise.

    For example, imagine trying allow a single user, Bob, to read one
    of your files. With traditional Unix file permissions, the only
    way to do it is to make a new group (say, "friends") with just two
    people in it, you and Bob. Then you'd change the file's group to
    be your new two-member group, and enable the group read
    permission.

This part is basically true.  On systems which allow a user to give
away ownership of files (some older Unix systems fall into this
category), it's possible to create a directory to hold the file, then
give the directory away to the user, providing read access to all on
the FILE, and no access to all on the DIRECTORY.  It's also possible
to do this on all existing Unix systems with intervention of the
system administrator.

    That was awkward, but now imagine that you want to let a third
    user, Ray, write to the file, but not read it. Now you're stuck.
    If you put Ray into the "friends" group, he'll be able to read the
    file. And if you grant write access to the "friends" group, then
    Bob can write to the file. Since a file can only have one owner
    and one group, there's nothing you can do. The Unix permission
    system is not flexible enough to accommodate these needs.

This part is patently false, though the solution may not be obvious to
people who are not REALLY familiar with how Unix permissions work.

First, it's worth noting that Unix permissions can be used to grant
privileges, and also to TAKE THEM AWAY.  For example, note the
following file:

  -rwx---rwx  1 ddm ddm 0 May  1 03:40 zero

In this case, users who are in the "ddm" group, other than ddm himself
(the owner of the file) have no access to this file, EVEN THOUGH FULL
ACCESS IS GRANTED TO WORLD.  Unix checks the permissions in order:
first the owner, then the group, and finally world.  It stops checking
as soon as the user matches one of those categories in that order.
Thus if the user is in group ddm, the permissions for world will never
be checked...

Now, let's return to our example.

You have a file, my_file, which you want Bob to have read access to.
You want Ray to have write access, but not read access.

This case isn't even all that hard.  Unix solves this problem with
ease and quite regularly.  An example is the system logs...  any user
can write to them (using the syslog command, or the syslog() function
call implemented in the C libraries, etc.)  This is done by having the
user write to the file indirectly through the syslog daemon, which
runs as root.  It need not be syslog though, and it need not be SUID
root.  A daemon can be created to allow users to write to such files,
and it can be owned by any regular user, so long as the files in
question have write access by the same user or group the program will
run as.

Another way to solve this problem is by creating a simple SUID wrapper
program.  SUID programs can be dangerous, but the required
functionality is quite simple and easy enough to code without causing
security problems.  Most importantly, if the file is owned by a
regular user, the script need not be SUID root...  only SUID that
user.  It should have group execute permissions, and a special group
should be created for users who should be allowed to run this wrapper
script.  This method can also be used to provide append-only
privilege, much as syslog does.  

The drawback to this method is that it does require that someone
create a special-purpose wrapper program to handle these kinds of
operations for each group which needs that kind of access.  On the
other hand, the need for write-only access to files is unusual, with
limited applications -- mainly logging and auditing -- and those can
and should usually be handled by specialized programs anyway.  So it's
not so unreasonable that it should be handled this way.

The far more common case is that one group of users should need read
and write, but another should only be able to read files.  There is a
third way, which is more general, and allows two distinct groups of
users to have different access, one type being read-only, the other
read-write.  Without using SUID/SGID programs.

So again, I have my_file.  I'm user ddm.  I want Bob to be able to
read my file, and I want Ray to be able to both read and write it.
You need two Unix groups to do this.  Call one readonly, the other
readwrite.  

One more point: providing write access to your home directory to
ANYONE other than yourself is a very bad idea.  Doing so will allow
any such user to delete anything and everything in your home
directory, unless you also set the sticky bit on your home directory.

This actually works to our advantage, because we'll want to create a
subdirectory to hold this file.  Let's call the directory access.
Create it with 750 permissions, with group readonly ownership.  Your
home directory (sans irrelevant files) will look like this:

  $ ls -la
  total 12
  drwxr-xr-x  3 ddm ddm      4096 May  1 04:09 ./
  drwxrwxr-x  8 ddm ddm      4096 May  1 04:08 ../
  drwxr-x---  2 ddm readonly 4096 May  1 04:09 access/

Then, in the access directory, set up your my_file file:

  -rw-rw-r--  1 ddm readwrite 0 May  1 04:13 my_file

Now, the trick is, BOTH groups of users (Bob and Ray) need to be added
to the readonly group, and only those who should be able to write to
the file (Ray) should be added to the readwrite group.  Bob will be
able to read the file, granted access to the "access" directory by
being a member of the readonly group, and granted read access to the
file by being a member of "world".  Ray will be able to write the
file, granted access to the "access" directory by being a member of
the readonly group, and granted write access to the file by being a
member of the readwrite group.

Delete-only access can also be provided this way.  The files in
question should be organized into a directory with group write privs,
and users who should be able to delete them should be placed in the
correct group.

Using this method really isn't that tough, but it DOES force you to
think about how your users are using their data, and organize where it
lives in the filesystem accordingly.  Detractors argue that ACLs are
better, because they're easier to set up, more flexible, and don't
require you to think so hard about your data.  My argument is that
Unix permissions are better, for precisely the same reason: they force
you to work in an organized, logical manner.  ACLs /are/ easier to set
up, but they can cause applications to break in hard to identify and
harder to fix ways when say, a particular application wasn't
anticipated, or when key people leave the company, etc.  Changing Unix
permissions on a directory full of files is fast and simple.  Changing
5000 individual ACL entries (or 500, or even 50 for that matter) on
the same directory on a Windows NT server is anything but...

I've actually worked at a company where different views of the data
was provided (through a document management system, specifically which
I forget) to different users by different ACLs on different vitural
paths to the data...  That caused access problems that turned out to
be absolutely IMPOSSIBLE to fix.  The "solution" was to repeatedly
change ACLs on the data to accomodate who needed to access it at any
given moment.  This problem was caused by poor organization and design
of the layout of the data, and could have been easily avoided if more
thought had gone into the process of organizing the data based on who
needed what access to it.  ACLs encourage people to work sloppily
because it's easier to do so.  Until the @#$! hits the fan, that is...

There are very few /practical/ permission scenarios that Unix
permissions can't handle.  ACLs suck.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail.  Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20050501/298bafea/attachment.bin