[kwlug-disc] Access rights to file/folder

[unsolicited]

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.

Yes.

> 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 
deal with.)
- 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 
to directories.

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.