Re: ACM permission

[John Haxby <jch@pwd.hp.com>]

robert byrne wrote:

> To summarize: the way to approach the "too many permissions" problem is
> to first agree on the functionality we are willing to drop, if any.
> After that whether we overload permissions or not is probably not
> critical.

I think that there's something else to consider here.   Some poor
administrator has got to configure this server somehow.   With 17 different
permissions (and probably even twelve) there's ample scope for screwing up
and letting information leak out that they didn't intend to leak out.

For example (and this is just an example, it's not even vaguely formal and
probably not correct), suppose that an admin doesn't want to let people
read an attribute called "std" or even know that it is present.  Under a
really simple scheme, this means just disabling read access.  Under a more
complex scheme, make sure you can't read it or test for presence.  All well
and good.  Except that "std" only has a small set of possible values so you
can compare it against those.

Another example, you don't want people to test for the presence of an
attribute.  Do you just disable that.  However, there's nothing to stop
someone downloading the entire directory and using "grep" on it.  Or
searching for "(|(std=a*)...(std=z*))" (or a filter that tests for starting
with one of the 65536 unicode letters).

The point here is not that fine-grained access control is a good thing or a
bad thing.  It is rather a question of balancing the likelihood of an
administrator inadvertantly granting more access than they intended versus
not having as much control as they would like.

Personally, I would tend towards simplicity.   Is it really worth
differentiating between "presence" and "read" is probably a bit subtle and
definitely a minefield.   Is it worth having "compare"?  It might be.  At
one time, this was a really good way of storing passwords -- you could test
them but you couldn't read them (these days I'm not so sure: without extra
checks and complexity it just supports dictionary attacks and you're better
off putting that defense into the authentication mechanisms).

Finally, just let me point a little feature of VMS privileges which are
extraordinary in their richness and variety and usefullness.  Two of the 32
obviously let you acquire any privilege.  Four out of the 32 do likewise,
but very few VMS administrators knew what they were ...

In conclusion, then, don't forget that while you're deeply embroiled in the
subtle nuances of different sorts of access that (a) administrators are
unlikely to have that degree of skill and (b) hackers will find and exploit
any unlikely holes.  Keep It Simple.

jch

begin:vcard 
n:Haxby;John
tel;fax:+44 1344 763686
tel;work:+44 1344 763711
x-mozilla-html:FALSE
url:https://ecardfile.com/id/jch
org:EPO R&D
adr:;;Hewlett Packard<br>Nine Mile Ride;Wokingham;Berks;RG40 3LL;United Kingdom
version:2.1
email;internet:jch@pwd.hp.com
x-mozilla-cpt:;-10592
fn:John Haxby
end:vcard