[3295] in Release_Engineering
Flag permissions change
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Tue Aug 9 15:22:52 1994
From: ghudson@MIT.EDU
Date: Tue, 9 Aug 94 15:22:42 -0400
To: macdiscuss@MIT.EDU, ops@MIT.EDU
Cc: rel-eng@MIT.EDU, srz@MIT.EDU, raeburn@MIT.EDU
The Mac Discuss developers have been suggesting that discuss
transaction-flagging should not be dependent on having delete
permission in a meeting. Currently, the servers overload the "d" bit.
Upon investigation, it seems that a one-line change in the server will
fix this. ACL entries are stored as strings, so you don't need to do
anything special to assign meaning to an ACL bit except look it up in
the appropriate place. Line 812 of /mit/opssrc/discuss/serve/core.c,
in set_trn_flags(), reads:
if (!has_trn_access(th_author,'d')) {
and could instead read:
if (!has_trn_access(th_author,'d')
&& !acl_check(mtg_acl,rpc_caller,"f")) {
I don't know if this is the cleanest change, but it's
backward-compatible. The "d" bit would mean "ability to change all
flags on a transaction", the "o" bit would mean the same for people
operating on transactions they authored, and the "f" bit would mean
"ability to change all flags on a transaction except DELETED".
There are other possible changes, which should be fairly obvious to
most readers, which assign different meanings to the acl bits in
relation to changing flags. (Note, in particular, that
has_trn_access(th_author,'d') checks the "o" bit if the transaction
author and rpc caller are the same, and you might want to do the same
for the "f" bit for some meanings of the "o" flag.)
At any rate, I'm just a poor Zephyr hacker, so I'll let the people
involved hash out the semantics; I just wanted to get past the
technical details.
