krowitz@RICHTER.MIT.EDU (David Krowitz) (09/08/89)
Ok, here's another one ... from my SR9.7 node I can "crp" onto a diskless node running SR9.7. From my SR10 node I can "crp" onto the same diskless machine *if* I am logged in as krowitz.sys_admin, but not if I am logged in simply as krowitz.my_own_group. I get an "insufficient rights" error when I am not sys_admin. Anyone know which set of acls on which files is causing this? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
crh@APOLLO.ENG.OHIO-STATE.EDU (Charlotte Hawley) (09/08/89)
Regarding the crp error - check the access rights on /dev/crp's There is a bug in SR10 that causes these to get messed up.
dbfunk@ICAEN.UIOWA.EDU (David B Funk) (09/08/89)
Re the "crp insufficient rights" error under sr10:
You have an ACL problem on `node_data/dev for the target
machine.
1) "/dev" must be world writeable for "crp" to work, at sr10,
as the SPM creates a new "/dev/crpXX" mailbox for each crp
session. Note that at sr9.7 the "crp_mbx001" was created in
`node_data, so the world didn't need "write" permissions to
"`node_data/dev", now at sr10 it does need "w" on "/dev"
2) There is a bug in "spmlogin" that causes it to create messed
up ACLs on the "/dev/crp00" mailbox, if you "crp" with the
"-login" option and then later do it again with "-me".
This only happens if you have Unix style inheretance for
the inital file ACL on "/dev". The error is a little confusing,
but the sequence looks like this:
First from SID "anything else" I do a crp to my ".locksmith" SID
Then later when I'm logged in as ".locksmith" I do a "crp -me"
$ crp -on //is7 -me
?(crp) Can't create remote process - client has no rights to server mailbox (library/MBX manager)
$ acl //is7/sys/node_data/dev/crp00
Acl for //is7/sys/node_data/dev/crp00:
Required entries
dbfunk.%.% prwx-
%.locksmith.% -rwx-
%.%.none [ignored]
%.%.% -----
Extended entry rights mask: -----
Now look at the ACL on "/dev" for that node:
$ acl //is7/sys/node_data/dev -all
Acl for //is7/sys/node_data/dev:
Required entries
root.%.% prwx-
%.sys_admin.% prwxk
%.%.is -rwxk
%.%.% -rwxk
Extended entry rights mask: -----
Initial (default) acl for directories created under //is7/sys/node_data/dev
Required entries For the current process:
[from process] [specified by process] dbfunk.%.% [specified by process]
[from process] [specified by process] %.locksmith.% [specified by process]
%.%.none [ignored]
%.%.% [specified by process]
Extended entry rights mask: -----
Initial (default) acl for files created under //is7/sys/node_data/dev
Required entries For the current process:
[from process] [specified by process] dbfunk.%.% [specified by process]
[from process] [specified by process] %.locksmith.% [specified by process]
%.%.none [ignored]
%.%.% [specified by process]
Extended entry rights mask: -----
If we change the initial default file ACL for the "/dev" directory,
the problems go away. The important thing is to have Aegis style
inheretance for the initial file ACL. Try an ACL like:
$ acl //is7/sys/node_data/dev -all
Acl for //is7/sys/node_data/dev:
Required entries
root.%.% prwx-
%.sys_admin.% prwxk
%.%.is -rwxk
%.%.% -rwxk
Extended entry rights mask: -----
Initial (default) acl for directories created under //is7/sys/node_data/dev
Required entries For the current process:
[from process] [specified by process] dbfunk.%.% [specified by process]
[from process] [specified by process] %.locksmith.% [specified by process]
%.%.none [ignored]
%.%.% [specified by process]
Extended entry rights mask: -----
Initial (default) acl for files created under //is7/sys/node_data/dev
Required entries For the current process:
root.%.% prw--
%.staff.% -rw-k
%.%.none -rw-k
%.%.% -rw-k
Extended entry rights mask: -----
There is a patch tape out with a new version of spmlogin that is supposed
to cure this problem also. However I found that setting the ACLs works
just fine.
Dave Funk