NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/mail/elm/3212

Text File | 1992-11-08 | 3.8 KB | 82 lines

Newsgroups: comp.mail.elm
Path: sparky!uunet!caen!spool.mu.edu!dsinc!syd
From: [e-mail] (Syd Weinstein)
Subject: Re: ELM 2.4PL6 - Big problem! Changing permissions on /usr/mail
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Organization: Datacomp Systems, Inc.  Huntingdon Valley, PA
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 7 Nov 1992 03:37:52 GMT
Lines: 70

[e-mail] (Doug Quale) writes:
>In article <[e-mail]> [e-mail] (Antoon Pardon) writes:
>>In article <[e-mail]>, [e-mail] (Daryl Erwin) writes:
>>|> HELP! HELP!
>>|>
>>|> I think there is a big problem with elm 2.4 (not necessarily just pl6).
>>|>
>>|> Our directories in /usr/mail/ (users mail directories) group permissions
>>|> are being chamed from 'mail' to some other group (their own).
>>
>>We have had similar problems here. The problem however was not elm
>>but a buggy NFS. The problems was that when a file was opened with
>>the CREAT flag over NFS and you where the owner of the file the group of
>>the file was changed to the gid of the process even if the file already
>>existed. As a workaround (This works only on bsd systems I think) we
>>set the setgid bit on the spooldirectory to indicate that created files
>>should get the gid of the spool instead that of the process. It works
>>for the moment.
>>

>If this is indeed the problem, it is a bug in Elm.  BSD and SYSV systems
>set the gid of newly created files differently.  In BSD, the gid = gid
>of parent directory, in SYSV gid = gid of creating process, unless the
>the parent directory is sgid when the BSD behavior is used.  POSIX permits
>either behavior.  If the gid of a newly created directory is important
>(and it certainly is here!), the only reliable thing to do is explicitly
>chown it to the desired group after the open.
Ok, I've got a problem here, and I've kept my big trap shut until now.

Perhaps its semanics, perhaps it isn't.  But, the original post
talked about Elm changing the permissions of directories in /usr/mail.
Elm doesn't deal with or touch directories in /usr/mail, only files.
So did the original user (Daryl Erwin) mean directories or files.

The second person talked about files that already existed and NFS
changing the group of an existing file.  Now, actually, Elm probably
did its usual copy to temp and copy back, so especially with NFS, where
the cross link would fail, it would be a copy back and not a hard link,
the original group id should not be changed.

But again, we go back to the master case, Elm copies the file over and
then links the new copy back into /usr/mail.  Elm does indeed do a
chown(file, user, group) back to the same user and group as the
original file.   (See leavembox for the code, its called
restore_file_stats.  So again, normally it should work (note that the
case where setgid directories is indeed needed, BSD, is the case where
only root can do the chown system call.)

So, we are still down to the original problem, which no one has bothered
to track down..... Why is sometimes the group id being changed, and is Elm
doing it?

Now, as my own systems two cents, We run SVR4 on our mailhost here,
and the mail spool is

drwxrwxr-x   3 root     mail         512 Nov  6 22:34 /var/mail

no, setgid there, and the mail files have never been changed from group
mail by Elm or by smail 3.1 (my MTA of choice).   So, this site hasn't
seen the problem.

So, my two cents: Someone who is experiencing the problem, you'll
have to investigate further as to what it is.


--
========================================================================
Sydney S. Weinstein, CDP, CCP          Elm Coordinator - Current 2.4PL06
Datacomp Systems, Inc.                 Projected 3.0 Release: ??? ?,1994
[e-mail] or dsinc!syd      Voice: [phone], FAX: [phone]