Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!umbc3!tron!kerr
From: kerr@tron.UUCP (Dave Kerr)
Newsgroups: comp.sys.apollo
Subject: Re: ACL problem with ~/mbox under SR10.2
Summary: mbox not owned by user?
Message-ID: <468@tron.UUCP>
Date: 19 Dec 89 23:40:58 GMT
References: <8912190007.AA04449@richter.mit.edu>
Reply-To: kerr@tron.wec.com (Dave Kerr)
Organization: Westinghouse Electric Corporation
Lines: 36

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