Pine 4: can't create lock file error (fwd)

[Sotiris Tsimbonis]

Tis teleytaies meres exei katakleistei to comp.mail.pine apo thn erwthsh
me ta permissions tou /var/spool/mail .. To parakatw e3hgei poly kala ti
ginetai me to kainourio Pine.

Sotiris.

PS. S'emena pantws douleyei mia xara san
drwxrwxr-x   2 root     mail         1024 Jul 16 19:41 /var/spool/mail/

---------- Forwarded message ----------
Date: Thu, 16 Jul 1998 05:50:10 GMT
From: Joachim Achtzehnter <joachim at kraut.bc.ca>
Newsgroups: comp.mail.pine
Subject: Re: Pine 4/FreeBSD: can't create lock file error

In article <01bdb046$98714000$35bba8cf at drpat>,
	"Pat" <drpat at vegas.net> writes:
>
> /var/spool/mail to 01777 did work... but I am a bit weary about these
> permissions being set on the mail spool dir...

Ok, let me try to explain the reasoning behind the 1777 permissions on
the mail spool directory. I hope I'll get it right :-)

First off, keep in mind that we are talking about the permissions on
the directory, not the files. We get to the files later.

The 777 by itself would give permission to everybody to list the
directory, create or delete files, and navigate to
subdirectories. Clearly this would be dangerous because user A could
delete user B's files. By adding the 1 in front, the permissions are
altered such that deleting of files is only permitted for the file's
owner. As a result, user A can no longer delete user B's inbox. It is
now desirable to ensure that every user always *has* a mailbox file
because otherwise user B could create a file with the name of user A's
mailbox, which user A would not be able to delete, hence a denial of
service attack. So with 1777 permissions you should avoid mail
programs which delete the mailbox when it is empty.

So, only the file's owner can delete it. The mail programs can create
lock files without a need to run as root. Nobody can delete other
people's files. The only remaining drawback is that everybody can
create files, possibly filling up the partition with rubbish. But
note, anybody having a legitimate mailbox would also be able to fill
the partition. The only difference is for people who have a login
but no mail account.

The mail files themselves can have permission 600, access only to the
owner. Nobody else can read them. User mail agents run without special
permission. The mail delivery agent starts as root but switches owner
to the receipient user before touching the spool file.

> any other way to get around this problem?

The other traditional approach is to set the directory such that only
mail or root can modify it. File ownership lets users modify the mail
file, but not the directory. This has the drawback that programs
without root/mail priviliges cannot create log files, hence Pine's
error message. All mail user agents would have to be SUID, which is
*very* undesirable. Or locking is compromised which can result in
lost emails.

Joachim

-- 
private:  joachim at kraut.bc.ca    (http://www.kraut.bc.ca)
work:     joachim at mercury.bc.ca  (http://www.mercury.bc.ca)


--
====================================================================
Gia boithia (h na diagrafhte) e-mail sto majordomo at argos.hol.gr
Ta archives tis listas einai sto http://www.argos.hol.gr/lists :
prin steilete kapoia erothsh psakte mipos exei hdh apanththei.
Gia opoiodipote problima stilte e-mail ston owner-linux-greek-users
====================================================================