Greg Kettmann said:
> I gather that Linux doesn't have any sort of inheritance and matches the
> OS/2 Windows model (which is good). It seems that the -R switch will
> allow you to "Apply" the permissions change to subdirectories. Do I
> have this right?
That's not quite true. If you set the SGID bit on a directory, files
and directories created within it will be created with the group id of
that directory. This can be done either with the numeric form of
chmod or the symbolic. If you use the symbolic form, you can add the
SGID bit without affecting other permissions:
# chmod g+s dirname
With the numeric form, you must specify the full permissions. This is
most often (but not always) done to accomodate allowing a group of
people to write files in the directory, so it's usually also done in
combination with making the directory rwx for the group, so that's
what I'll show. In other words, you want drwxrwx--- permissions on
the directory.
# chmod 2770 dirname
^
| SGID bit
Certainly you might wish others to have read access... this is just a
common example.
>
> ============= Groups to manage access ==============================
>
> I need to understand how to use groups better. Let's build two
> subdirectories. /shared and /accounting. Where they are is
> irrelevant. In my past I'd have a group called "everybody" with every
> user on the system in it. If I want to give access to /shared to
> everybody it seems all I'd have to do is assign the group everybody to
> the /shared subdirectory.
The "everybody" group is obviated by the "other" permissions, which is
essentially everyone. (Actually that's not quite true...)
> Likewise I want to restrict /accounting to members of the accounting
> department. I build a group called accounting and only the members of
> the accounting department will be in that group. It would look like:
>
> ls -al /accounting
> drw-rw---- 19 root accounting 4096 Aug 8
> 11:01
You probably also want the execute bit (x) set on directories...
Otherwise you will not be able to cd into them! Otherwise, this makes
sense.
> Finally, how would I handle multiple groups? For example I'd like the
> auditors to be able to only have read access. In my past I'd simply
> assign multiple groups to the subdirectories but I don't see how to do
> this, in this environment, or at least to give more than one set of
> permissions. I don't want to open it up to read for everybody.
This is my favorite trick with Unix permissions. What you're saying
is you basically have three groups of people you want to have
different access:
accountants = read and write
auditors = read
everyone else = none
The only way I've been able to figure out how to do this involves
creating an extra top-level directory, which in this case maybe
"finance" is an appropriate name. You'll create this directory with
the following permissions/ownership:
drwxr-x--- root finance ... finance
Now, all auditors and accountants need to be in the finance group.
You'll then create the accounting directory in the finance directory.
drwxrwxr-x root accounting ... accounting
Since both groups of employees will be in the finance group, they will
both have access to the finance directory, but no one else will.
Then, accountants (being in the accounting group) will have rwx access
to the accounting directory, and the auditors will have r-x access.
No one else will have access, even though the accounting directory is
r-x for "other" because the --- permissions for "other" on the finance
directory prevents them from having access to anything below the
finance directory.
This scheme is a little complicated and wastes a group, but your only
other alternative (that I know of) is to use ACLs, which have their
own drawbacks:
- not supported by the stock kernel (or any vendor kernel that I
know of)
- don't work with all filesystems
- may not work with NFS (I think this depends on the ACL patch you
use -- there are several different projects as I understand it --
but I'm not positive about this)
- make it all too easy for your ACLs to become a complicated web of
interdependencies that is very difficult to maintain and clean up
Personally, I hate ACLs and don't see the need. I think they're
much harder to manage _WELL_ than to use Unix permissions, and
encourage taking the easy way out as opposed to thinking about your
problem and providing an elegant, sensible solution. In my
experience, after some months or years of managing ACLs, they have a
tendency to become very messy, and cause things to break unexpectedly
and in ways that are difficult to fix, when say, people leave the
company, or when you need to re-design the way your data is stored.
--
Derek Martin
Senior System Administrator
Mission Critical Linux
[EMAIL PROTECTED]
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
