[kwlug-disc] Access rights to file/folder
unsolicited at swiz.ca
Thu Jul 29 01:24:06 EDT 2010
John Van Ostrand wrote, On 07/28/2010 5:16 PM:
> ----- Original Message -----
>> --- On Wed, 7/28/10, John Van Ostrand <john at netdirect.ca> wrote:
>> Except if there are some Legal documents that HR must have access
>> to. Then you need to create that other group and maybe the head
>> of HR may need access to a different "Legal Documents" subset
>> that other HR people don't have access to.
> Then it is classified differently.
> Isn't this what security is all
> about. Classifying data and assigning permissions?
In the windows world, at least, these resource groups are the only
sane way to manage things, and you will still pull your hair out.
[This is not due to the technical, but because this is 'human (access)
engineering', and staff, tasks, and responsibilities, are constantly
changing.] (As John said, many times, (admins resist) for fear of
breaking something. As a result, kludges get implemented, and things
get worse and worse.) This is a prime example of where a change
logging system is really useful - when Joe calls up because he can no
longer get to a file, a quick review of where the file is vis a vis
recent changes not only leads to a quicker diagnosis and resolution,
but a more refined solution to that prior change. This is also an area
in which change management and accountability and I.T. staff authority
to resist managers must be well understood. e.g. A Payables Manager
has no authority to add (but can remove) someone to something owned by
Receivables. But the Receivables Manager has the authority to do
whatever he wants - it's his directory. This may annoy the Payables
Manager, but the I.T. staffer must resist the intimidation. The
solution in this case is to create another directory, and therefore,
resource and directory group. Pedantic, but it works, somewhat sanely.
- this is all culture change, and can be painful. It has more to do
with people, than technology.
When an initial disciplined approach is used, and RIGOROUSLY (yeah,
right) adhered to, it works well, and makes life simpler.
Unfortunately, usually such is laid on after the fact. Ce la vie.
'Resource' is such an unfortunate use of the term (but doesn't
originate with John), as resources mean different things to different
people, at different times. In this case, all it means is a particular
combination of people and permissions.
In the given case, the H.R. manager should not have write access. Much
like passwords - never give your password out, admins can change it if
they have to, then inform you, so at least you know something went on.
If the manager needs to change something, they take a copy, do their
thing, then turn it back to the owner for updating. Again, the user
knows something happened, and can't be called to task for document
changes apparently made that they weren't aware of. To the managers:
deal with it. Anything else is unfair to the user.
Part of why resource groups work, and part of the complexity and great
irritation, is groups can contain groups. So, (I.T. Support) <- (I.T.
Admins.) <- (I.T. Dept.) <- All Employees -> (Acct. dept.) -> (Acct.
Supervisors) -> (Acct. Payables) -> (Acct. Clerical). It is an
irritating process to get in to (mostly because the users themselves
aren't used to thinking in terms of permissions), but once in place,
works quite elegantly.
There are some caveats.
- Use grp in the name. When you use group's within group's it helps
make it self-evident what's going on. Yes, the names get very long.
Deal with it. Adopt a naming convention - don't make me hunt.
- Arguably, you have two sets of groups - 'people' groups, and
'directory' [or file] (resource) groups. The directory group owns the
directory - that will never change as the directory is always there.
You then assign people groups to these directory groups. Admins will
more readily change things then, as they're certain they are only
affecting this one directory. [Don't forget, you can allow permissions
at the top, then deny below. e.g. All Managers may be given read at
the top, then particular managers denied read at the bottom. This
makes each set of directory permissions weird, but at least they are
all kept in one place to look.]
- in reality, you have many more groups. A group root based on
location. A group root based on authority (managers, e.g. generic
memos to all managers). Group roots based on departments. And group
roots based on special cases - e.g. I.T., accounting, H.R.
- a solid 'design' document really helps.
- a perms change log really helps. (Remove someone from a group, and a
week later when they can't get into something else, becomes easier to
- something like a .perms file in each directory, indicating what the
permissions are supposed to be, perhaps with a changelog, can be
useful. What permissions were designed to be, and what they actually
are, are never the same thing.
- if .perms could somehow be scriptable, sanity checks can be run - if
actual permissions and what .perms says are different for any given
directory, it can be flagged.
In essence, you create two or more 'LDAP' trees - groups of people,
and groups of permissions to a directory. Then apply groups of groups
Speaking of LDAP, how do ACL's fit into the Linux LDAP world?
BTW - the broad strokes evolved out of e-mail groups. Dept. memos,
Building memos (garage sweeping), (All) Manager memos, All employee
memos. The difference when moving to file permissions was assigning a
new group per directory. Then populating that directory group with
these other groups. Directory groups also accumulate, e.g.
accounting/payables and accounting/receivables. receivables + payables
= accounting. Here, only payables and receivables contain people. The
accounting group consists of the other two groups.
My attitude used to be: If you can't trust your people not to be
nefarious, you may as well pack it in and go home. (Security and
permissions are a lot of shouldn't be necessary busywork.) I've had to
change that - since Barney may accidentally 'rm fred', sending Fred up
the creek through no fault of his own.
More information about the kwlug-disc_kwlug.org