krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (12/19/89)
I've just installed SR10.2 on about 1/2 of my machines (up from SR9.7), and my users are noticing that everytime they read their mail the ACL on the "mbox" file gets changed so they no longer have any rights to it. I've reset the ACL several times (and checked the initial ACL for the home directory) and each time the ACL gets closed up again. Anyone have any idea what is going on? -- 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)
kerr@tron.UUCP (Dave Kerr) (12/20/89)
In article <8912190007.AA04449@richter.mit.edu> krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: >I've just installed SR10.2 on about 1/2 of my >machines (up from SR9.7), and my users are >noticing that everytime they read their mail >the ACL on the "mbox" file gets changed so >they no longer have any rights to it. I've >reset the ACL several times (and checked the >initial ACL for the home directory) and each >time the ACL gets closed up again. Anyone have >any idea what is going on? > > We had a similar problem. The bottom line was that when we used /com/cpt -conv -pdt -sacl to move the user's home directories over to sr10 from sr9.7, the owner, group and org entries were set to "none", the user was added as an extended acl entry. When mail saves a message into ~/mbox, it (apparently) does a chmod to restrict access to the file. Chmod sets the permissions as expected but also sets the extended acl mask to all -'s effectively removing the extended acl entry. It's interesting however that our first sr10.1 (unpatched) machines set the acls so the user was the owner when you did a cpt -conv, one of the patches we installed stopped this from working in this manner. The man page for cpt says that the -conv option should add entries in as extended acl entries, so apparently the command is not "fixed" although I perfer the broken version :-). -- Dave Kerr (301) 765-4453 kerr@tron.bwi.wec.com from an Internet site kerr@tron.UUCP from a smart uucp mailer
dbfunk@ICAEN.UIOWA.EDU (David B Funk) (12/21/89)
In posting <8912190007.AA04449@richter.mit.edu> David Krowitz asks: > I've just installed SR10.2 on about 1/2 of my > machines (up from SR9.7), and my users are > noticing that everytime they read their mail > the ACL on the "mbox" file gets changed so > they no longer have any rights to it. Per chance when you say "they no longer have any rights to it" do you mean that they no longer 'own' it? Is it the case that that they still own it but can't get at it or is it the case that the mbox becomes owned by "none"? If it is the case that they still own it but have no rights to it then check the value of their "umask". If it is the case that the file becomes owned by "none" then here's what may be happening: One of the problems of running a mixed sr9.7 - sr10.x network is caused by an incompatability of the ACL systems. sr10 has a 2 level ACL system, the mandatory ACL entries and the optional extended ACL entries. sr9.x only has what could be called mantitory "extended" ACL entries. All sr9.x ACL entries get mapped into the sr10 "extended" ACL entries, sr9.x cannot express to sr10 the mandatory "ownership" entries. When a sr9.x system changes the ACL on a sr10 object (a file or dir on a sr10 machine) all the required "ownership" entries get 'nulled out' and all the info gets pushed down into the "extended" entry. Thus the object loses its 'ownership' as seen by the sr10 system. Here's the big pain: If a user has his/her home directory on a sr10 machine and changes the ACL (protections) on an object, while logged into a sr9.7 machine, then he/she loses 'ownership' of that object as seen by sr10. It will look OK from a sr9.7 machine but when you go to a sr10 machine, it will be FUBAR. Where this is a real problem is that many Unix utilities (like most of them) love to do "chmod"s on files that they create/modify. So if your home directory is on a sr10 machine and you use Unix (Domain/IX) from a sr9.7 machine, then you will make a mess of the sr10 ownership of your stuff. For example: Here's the ACLs on a "mbox" file in my sr10 directory, as seen from the sr10 machine: $ acl ~/mbox Acl for ~/mbox: Required entries dbfunk.%.% prw-- %.sys_admin.% ----- %.%.none [ignored] %.%.% ----- Extended entry rights mask: ----- Here's the ACLs on the same file in my sr10 directory, as seen from a sr9.7 machine: $ acl mbox Acl for mbox: dbfunk.%.%.% pgndwr- %.sys_admin.%.% --nd--- here I do a "chmod" on that same file from the sr9.7 machine $ chmod 600 mbox $ acl mbox Acl for mbox: dbfunk.%.%.% pgndwr- %.sys_admin.%.% --nd--- %.backup.%.% --n--r- Now I go back to the sr10 machine and look at its ACL: $ acl ~/mbox Acl for mbox: Required entries none.%.% [ignored] %.none.% [ignored] %.%.none [ignored] %.%.% ----- Extended entry rights mask: prw-k Extended entries dbfunk.%.% prw-- %.sys_admin.% ----- %.backup.% -r--k $ ls -l mbox -rw-rw-rw-+ 1 none 17276 Dec 21 01:19 mbox Note that now (according to sr10) the file is 'owned' by "none". There are entries in the extended ACL that give me rights to the file, but according to "stat" I no longer own it. Dave Funk