Derek's Unix Sysadmin tip of the day

[invalid-yPs96gJSFQo51KKgMmcfiw at public.gmane.org (Derek Martin)]

I'm surrounded by smart people who know Unix/Linux very well, but from
time to time I still hear that people think what I'm about to describe
is impossible.  I typed most of this up for a reason that became
superfluous by the time I was done, so I figured I'd share it with you
all, and at least *someone* is bound to find this useful. :)

The problem is this:  How do you give write access to a file to one
group of users, and give read access to a second group of users, while
giving NO access to all the rest of the users on the system?  Unix
only allows for the owner, a named group, and everyone else...

I assure you, you don't need extended ACLs to solve this problem; Unix
is perfectly capable to handle it.  The answer is, you use directory
permissions.  You may still be unconvinced, so I will explain in
detail.  [Astute readers will note that the case I describe below can
be optimized a bit.  The method below is the most general and assumes
that neither group is a subset of the other, nor can it be treated
that way, due to access restrictions on other files not considered.]

You have two groups that need access.  You need THREE Unix groups to
put them in... each user in those two groups will be put in exactly
two of the three Unix groups.  In our example, we have some
accountants who need to create accounting documents, and need to be
able to change those documents.  We also have a group of auditors, who
need to be able to read the documents, but must not be allowed to
write to those documents.  We create the obvious two groups: accnting,
and auditors, and put the users in their respective Unix groups.  The
key is, we add a third Unix group, let's say finance, and put all of
the users in BOTH groups in the finance group:  

accnting:x:750:user1,user3
auditors:x:751:user2,user4
finance:x:752:user1,user2,user3,user4

Then, as root, you set up the directory structure you will need to make this
work:

[/tmp] $ sudo mkdir /tmp/finance
[/tmp] $ sudo chgrp finance /tmp/finance
[/tmp] $ sudo chmod 2770 /tmp/finance
[/tmp] $ ls -ld /tmp/finance
drwxrws--- 2 root finance 4096 2009-10-23 23:41 /tmp/finance/
[/tmp] $ sudo mkdir /tmp/finance/accounting
[/tmp] $ sudo chgrp accnting /tmp/finance/accounting
[/tmp] $ sudo chmod 2775 /tmp/finance/accounting
[/tmp] $ sudo ls -ld /tmp/finance/accounting
drwxrwsr-x 2 root accnting 4096 2009-10-23 23:44 /tmp/finance/accounting


But there's one last problem here.  An accountant goes in and creates
an accounting file.  He's always dealing with sensitive data, so his
umask is set to 027, so no one who isn't supposed to can mess with his
data.  All well and good.  Then he creates his file:

[/tmp] $ sudo su user1
[/tmp] $ id
uid=750(user1) gid=750(accnting) groups=750(accnting),752(finance)
[/tmp] $ cd /tmp/finance/accounting 
[/tmp/finance/accounting] $ echo this is an accounting file > actfile1
[/tmp/finance/accounting] $ ls -l actfile1
-rw-r----- 1 user1 accnting 27 2009-10-24 00:05 actfile1

Now, at this point, only that user can write to the file.  He needs to
make it so that the other accountants can modify it, and the auditors
can read it (but NOT write to it)!  So he does this:

[/tmp/finance/accounting] $ chmod 664 actfile1
[/tmp/finance/accounting] $ ls -l actfile1
-rw-rw-r-- 1 user1 accnting 27 2009-10-24 00:05 actfile1

But wait, this file is world readable!  Doesn't that mean any user on
the system can read it?!?!?   NO, it doesn't.  Why not?  Because the
directory permissions leading to this file prevent that...  Remember
how we set up /tmp/finance?  Like this:

[/tmp] $ ls -ld /tmp/finance
drwxrws--- 2 root finance 4096 2009-10-23 23:41 /tmp/finance/

We needed that extra directory level to act as a gate, to keep out the
riff-raff.   So only users in the finance group can descend below
/tmp/finance, which includes everyone in the accnting group, and
everyone in the auditors group.  Then, /tmp/finance/accounting is at
least readable and cd-able (the execute bit) by everyone... so again,
both groups can cd to that directory, but all other users will be
prevented by the more strict permissions on /tmp/finance.  We can
confirm that this is true for our auditor (user2):

[/tmp/finance/accounting] $ exit
[/tmp] $ sudo su user2
[/tmp] $ id
uid=751(user2) gid=751(auditors) groups=751(auditors),752(finance)
[/tmp] $ cd /tmp/finance/accounting/
[/tmp/finance/accounting] $ cat actfile1 
this is an accounting file
[/tmp/finance/accounting] $ echo foo > actfile1
sh: actfile1: Permission denied

Perfect: the auditor can read the file, but can not write to it, even
though it is writable by other accountants.  We can also show that
other users can not access this file:

[/tmp/finance/accounting] $ exit
[/tmp] $ sudo su user3
[/tmp] $ id
uid=752(user3) gid=600(staff) groups=600(staff)
[/tmp] $ cd /tmp/finance/accounting/   
sh: cd: /tmp/finance/accounting/: Not a directory
[/tmp] $ ls -l /tmp/finance
ls: cannot open directory /tmp/finance: Permission denied
[/tmp] $ cat /tmp/finance/accounting/actfile1
cat: /tmp/finance/accounting/actfile1: Permission denied

The shell gives us a weird error when we try to cd
(/tmp/finance/accounting/ most certainly is a directory), but
otherwise we get exactly what we expect: this user, who is not a
member of the finance group, nor accnting nor auditors, can access any
part of this tree from /tmp/finance down.  This is exactly what we
want.

So, think Unix suffers for not having extended ACLs?  Poppycock, I
say!  (Of course it has them, if you really really really want them,
but...)  You just need to think about how to organize your users and
data into groups that make sense.  There are some limitations on group
memberships, especially with NFS, but if you exceed them, it probably
means that either your data organization needs some more work, or
you've got some folks with WAY, WAY too many hats.  =8^)

-- 
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 due to spam prevention.  Sorry for the inconvenience.