Subject: Record Locks & Permissions

From: Tony Rose <[email-masked]>
Date: Sun, 11 Apr 1999 23:05:37 -0400 (EDT)

In researching another problem today, my vendor found that the permissions
were wrong on my /var/mail directory. I had been allowing write
permissions for other and they removed it.

/var/mail was drwxrwxrwx
/var/mail now drwxrwxr-x

However, now when users go into Pine, they get an error message saying
that a lock cannot be established on var/mail/xxx. Operation seems to be
fine sending and receiving mail. But this error is annoying. Why does Pine
need this lock, and can it do it somewhere else other than /var/mail? My
vendor says that the permissions on /var/mail should stay as they have
left them. How do others get arround this?

________________________________
Tony Rose
Elon College 
Unix/Email Administrator

E: [email-masked]
V: (336)538-6815
F: (336)584-2447

2400 Campus Box
Elon College, NC 27244
________________________________

-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: Jessica Rasku <[email-masked]>
Date: Sun, 11 Apr 1999 21:50:15 -0700 (PDT)

> left them. How do others get arround this?

	Your vendor is wrong.  The permisions should be:

armispian:~$ ls -ld ~mail
drwxrwxrwt   2 root     mail         1024 Apr 11 21:00 /var/spool/mail/

	I believe (I could be mistaken here), that is 1777.  I also
believe that Pine probably complains if your mail spool is 0777 as you
had it setup, but I could be mistaken.  I KNOW that I read this somewhere,
it is in the release notes, if you do a ``wheris'' for lock, it will come
up, with a fairly thorough explanation in the ``what system managers
should know about file locking''.  

							Jessica

-- 
Jessica Rasku, Box 270, Rossland, B.C., V0G 1Y0, (250) 362-5701, 
LinuxBox: (250) 362-9668.

List manager: [email-masked] 
     send command help ---- To get help with majordomo
               or lists ---- To get a list of all lists on server.

WWW: <http://www.geocities.com/RainForest/Andes/8749>

---

From: Prince Of Angels <[email-masked]>
Date: Mon, 12 Apr 1999 00:32:17 -0400 (EDT)

> permissions for other and they removed it.

As far as I know a world writable mail directory isnt a problem, as long
as individual mail files arent. At worst you can get some stupid user (
then again, why would you have that ) to put some garbage in the
directory..

> left them. How do others get arround this?

You would obviously get this error as pine tries to make a lock file and
cannot. You need this lock to ensure that no mailbox corruption occurs
when multiple processes try to access the file. Other dont go around it we
live with it. As far as I'm concerned I never had a problem with this
particular thing. You might also wana disable the locking (really evil) if
you think its the right thing to do...

I belive you might find the Pine FAQ interesting if you look at section
7.5 and folowing concerning lock files regarding this subject.
( I would paste you the info but at this time washinton.edu seems to be
cut off by the verio.net pseudo-network )

As I remember tho they do adress this particular issue.

Best Regards
Masial

---

From: [email-masked]
Date: Mon, 12 Apr 1999 08:13:20 -0700 (PDT)

On Sun, 11 Apr 1999, Tony Rose wrote:
> Date: Sun, 11 Apr 1999 23:05:37 -0400 (EDT)
> From: Tony Rose <[email-masked]>
> To: Pine Discussion Forum <[email-masked]>
> Subject: Record Locks & Permissions
> 

Pine will stop complaining with /var/spool/mail or /var/mail, depending on
your system, set as its supposed to if you make the pine executible SGID
with a group of "mail".  With many systems, daemon doesn't run as root and
needs for all fo the files set to group write with a group of mail, the
SGID with a group of mail for pine works with this.

George L. Westlund           || Internet:   [email-masked]
ITS-UNIX/Distributed Systems || UNIX System:[email-masked]
Cal Poly                     || Phone/FAX:  (805)756-6543/(805)756-1536
San Luis Obispo, CA  93407   || Web Page:   http://www.calpoly.edu/~gwestlu/

---

From: Jessica Rasku <[email-masked]>
Date: Mon, 12 Apr 1999 11:08:13 -0700 (PDT)

> SGID with a group of mail for pine works with this.

	This is NOT advisable.  Pine is designed as a user level program
that is not intended to be SGID or SUID to run.  To do so introduces
security problems.  This is in the release notes.  If you MUST do it, than
do it, but it is much better to follow the sugestions that are provided by
the Pine development team, and set the spool dir permisions to 1777.  This
is NOT a security risk (well, the posibility of users putting ``random
files'' into the spool dir).  Or, preferably, spooling the mail in the
user's home directory (for security reason's at least).

							Jessica

---

From: [email-masked]
Date: Mon, 12 Apr 1999 23:54:33 +0100

> then again, why would you have that ) to put some garbage in the

Or delete other people's mail files.

That's why you really want the +t.

---

From: Scott Leibrand <[email-masked]>
Date: Mon, 12 Apr 1999 18:56:55 -0700 (PDT)

Sounds like you ran into the power outage that brought down a good part of
our network (and a few dorms) for a few hours.  Sorry about that.  :)

-- 
Scott Leibrand
[email-masked]
* RCW 19.190 notice: This email address is located in Washington State. *
* Unsolicited commercial email may be billed $500 per message.          *

> On Sun, 11 Apr 1999, Tony Rose wrote:
<snip>
> cut off by the verio.net pseudo-network )
<snip>

---

From: Tony Rose <[email-masked]>
Date: Mon, 12 Apr 1999 22:17:16 -0400 (EDT)

Yes. This is what I am worried about. What does the t do?

---

From: Timothy J Luoma <[email-masked]>
Date: Mon, 12 Apr 1999 22:39:58 -0400

> Yes. This is what I am worried about. What does the t do?

This is relatively basic Unix sysadmin stuff.....

from: man 2 chmod:

     If mode S_ISVTX (the `sticky bit') is set on a directory, an
     unprivileged user may not delete or rename files of other
     users in that directory.  For more details of the properties
     of the sticky bit, see sticky(8).

from: man 8 sticky:

     A directory whose `sticky bit' is set becomes an append-only
     directory, or, more accurately, a directory in which the
     deletion of files is restricted.  A file in a sticky directory
     may only be removed or renamed by a user if the user has write
     permission for the directory and the user is the owner of the
     file, the owner of the directory, or the super-user.  This
     feature is usefully applied to directories such as /tmp which
     must be publicly writable but should deny users the license
     to arbitrarily delete or rename each others' files.

TjL

---

From: Edmund GRIMLEY EVANS <[email-masked]>
Date: Tue, 13 Apr 1999 09:17:09 +0100

> Yes. This is what I am worried about. What does the t do?

On a directory it means don't let people delete files that they don't
own. It is typically used for public directories like /tmp:

bash$ ls -ld /tmp
drwxrwxrwt  80 root     root        29696 Apr 13 09:05 /tmp

(Unix file permissions are a bit counterintuitive at times: sometimes
you can delete a file and replace it by a similar one, even when you
can't write to the file, and sometimes you can write to a file, or
truncate it to zero length, even though you can't delete it.)

Edmund

---

From: Daniel Sands <[email-masked]>
Date: Wed, 14 Apr 1999 08:32:56 -0600

Okay, this is off-topic, but I am curious.  Is there any rationale for this?
Is it a bug, or a feature that anybody can delete a file in a world-writable
directory even if one cannot read or write that file?