Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ICAEN.UIOWA.EDU!dbfunk
From: dbfunk@ICAEN.UIOWA.EDU (David B Funk)
Newsgroups: comp.sys.apollo
Subject: Re: ACL problem with ~/mbox under SR10.2
Message-ID: <8912210803.AA00930@icaen.uiowa.edu>
Date: 21 Dec 89 07:28:59 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Lines: 93

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