Blake_Coverett@CMR001.BITNET (Blake Coverett) (11/30/88)
I have a problem with the way the ACLs and the DOMAIN/IX permissions mesh, or don't as the case may be. The situation is this, if I have a file on which the acl has %.%.%.% ------- as an entry then any use of chmod on this file results in %.%.%.% ---d---, even something of the style chmod 700 filename. However, if the %.%.%.% entry already has read access, then this does not occur. I am running sr9.7 on a ring of 30 DN3000s and 3 DN4000s. Does anybody have any ideas? The following is a copy of exactly what happens ------------------------cut here------------------------------ % /com/acl test Acl for test: blake.%.%.% pgndwrx %.backup.%.% -----r- %.sys_admin.%.% pgndwrx %.%.%.% ------- % chmod 700 test % /com/acl test Acl for test: blake.%.%.% p-ndwrx %.sys_admin.%.% ---d--- %.backup.%.% -----r- %.%.%.% ---d--- % su user Password: B$ rm //cmr_1/users/etud/blake/test rm: override protection 700 for //cmr_1/users/etud/blake/test? y B$ *** EOF *** % ls test test not found ------------------------end here------------------------------- CP6 : Blake Coverett @CMR ____ BITNET: <COVERETB@CMR001.BITNET> / ) ) ) 4 sqn CMR, St-Jean PQ. J0J 1R0 _____ /____/ / __ ) /__ __ "There are three classes of men: / ) / / / /\ /__) Those who see; /____/ ( (__( ( \ (__ Those who see what they are shown; and, Those who do not see." -Leonardo Da Vinci
GBOPOLY1@NUSVM.BITNET (fclim) (12/03/88)
blake coverett writes about the mis-mesh between aegis /com/acl
and domain/ix /bin/chmod.
after chmod-ing test to 700, he gets % -d- in the acl. then
he su to *root* and rm test.
if he had done an ls -l on test, he would get -rwx------. and i
suppose that if he had done an ls -l on the directory containing test,
he would get drwxr-xr-x or something similar. ie
% ls -ld .
drwxr-xr-x * coverett * * .
thus, root has no write permission on the parent directory.
but root is root. unix allows root to do anything. since root
has no write permission on the holding directory, unix seeks an answer
to overwrite the 700 permission on test. if that answer is 'y', unix
will delete the file, irregardless of the write permission on test.
if blake has switch user to some account other than root, he'll
find that he *can't* rm test.
i suppose that blake is confused with the fact that a 'd' in the
acl of a file means permission to rm or /com/dlf. the man page on
/com/edacl says that a file needs 'd' on its acl and a 'e' on the acl
of its parent directory. (unix only requires a 'w' on the permission
of the parent directory; unix will ignore the permission of the file
itself).
/* end of help */
/* *flame* on */
what i don't understand (and don't like) is why apollo.com has
introduce such complications into file system permissions. i like
the idea of an access control *list* whereby i may be able to give
permission to a narrower group of users irregardless of which group
the sys_admin has put me into.
i don't like the 'pgnals' options. if i allow user foo to read
a file, and he wants user bar to read it as well, he doesn't need
the 'p' option; foo can just cp or mail the file over to bar. if
foo is ethical, he would inform me before mailing the file to bar.
in that case, i would give bar the permission to read as well instead
of foo mailing it to bar. if foo, bar and i are in a project group,
i would give both of them the 'r' and 'w' (?) rights at the onset.
i don't understand the 'g' acl right; it just introduce
complications to understanding the concept of acl. in the polytechnic,
we have never remove the 'n' right; all nodes has access to all objects
on the file system. furthermore, i believe the network licencing scheme
would cover this. the 'als' rights are covered by unix more simpler:
'a' and 'l' are similar to unix's write permission in the parent dir;
's' being similar to 'x' in the parent dir under unix.
i accept the 'c' and 'e' rights, although i think the 'c' permission
should just be restricted to deleting links; i can't see why my project
members want to rename the file that i create. (they may edit the file
and use dsee to inform of the change). but i wouldn't allow any other
random users to rename my files. (they may read and/or execute).
if apollo.com removes all the rights that i have mentioned, then
their manuals would be simpler and more people will be less shy of acls.
/* *flame* off */
#include "std-disclaimer.h"
static char *str="the above opinions and misconceptions are mine and mine
alone";
fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513.