Subject: mailbox with 1777 protection

From: Claus Atzenbeck <[email-masked]>
Date: Fri, 9 Apr 2004 19:56:22 +0200 (CEST)

Hi,

I use Pine 4.58 on MacOS X. My mailbox file has the following rights:

-rw-rw----    1 claus    mail          553 Apr  9 16:07 /var/mail/claus

Whenever I start Pine, it complains:

[{localhost}inbox : Mailbox vulnerable - directory /var/mail must have 1777 protection]

Is there a deeper reason why my mailbox should have 1777 protection?

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

---

From: Eduardo Chappa <[email-masked]>
Date: Fri, 9 Apr 2004 13:04:22 -0700 (PDT)

*** Claus Atzenbeck ([email-masked]) wrote in the...:

:) Is there a deeper reason why my mailbox should have 1777 protection?

Yes, it has todo with sharing sessions with other programs that access 
your mailbox (like the delivery program) or other clients that you could 
use any other time to read your e-mail.

There is full information in the release notes. Press M R and then read 
the information on folder locking.

Eduardo
http://www.math.washington.edu/~chappa/pine/

---

From: Claus Atzenbeck <[email-masked]>
Date: Fri, 9 Apr 2004 22:48:14 +0200 (CEST)

> use any other time to read your e-mail.

Thanks for this information. There are only two things I am still
uncertain about:

I use Pine exclusively for my local IMAP service. IMAP takes care of
locking. Because of this, I don't need the Pine locking mechanism,
right?

Another strange thing: As soon as I start a 2nd Pine instance, I get a

    [{localhost}inbox : Trying to get mailbox lock from process 20648]

message, which does mean that there is a lock somewhere even though
/var/mail is not 1777 protected (it is rwxrwxr-x with root.mail). Any
idea where Pine gets this information from if there is no lock file?

Thanks!!

Greetings,
Claus

---

From: Mats Dufberg <[email-masked]>
Date: Fri, 9 Apr 2004 22:33:58 +0200 (CEST)

> Is there a deeper reason why my mailbox should have 1777 protection?

This topic has been covered more than once before in this mailing list.

Traditionally, file locking was done with lock files. For that to work
with different users, 1777 pretection is needed. Pine falls back to lock
files if other methods do not work (or it might be that it always creates
lock files in case).

Under FreeBSD I've come to the conclusion after some tests with locking
that locking works the modern way, and 1777 is not needed. There is a
setting in pine to make it ignore the problem (from pine's point of view).

Mats

-----------------------------------------------------------------
Mats Dufberg                                      [email-masked]
Blaoarvsgraend 42                                  +46-8-38 48 59
SE-162 45 Vaellingby, Sweden                      +46-70-258 2588

---

From: Mats Dufberg <[email-masked]>
Date: Fri, 9 Apr 2004 23:23:40 +0200 (CEST)

> locking. Because of this, I don't need the Pine locking mechanism,

If you only access mail through IMAP, file locking is not needed. But it
be that the IMAP-server need file locking. If you use UW-IMAP server it
accesses files exacly the same way as pine (the use the same code).

> idea where Pine gets this information from if there is no lock file?

As I said in my mail, lock files are not the only way to lock files. On
the contrary, using semaphores is the prefered method, and then no lock
files are needed.

If you do get the above message, I suspect that you have missed something
in the configuration. I seems like pine is accessing directly.

If you want to have several pine sessions open at the same time (on the
same or different computers) and you access mail directly from pine or you
use UW-IMAP server, I'd suggest that you look at MBX as the file format
for the mail boxes.

Mats

---

From: Eduardo Chappa <[email-masked]>
Date: Fri, 9 Apr 2004 15:02:45 -0700 (PDT)

*** Claus Atzenbeck ([email-masked]) wrote today:

:) On Fri, 9 Apr 2004, Eduardo Chappa wrote:
:) 
:) > *** Claus Atzenbeck ([email-masked]) wrote in 
:) > the...:
:) >
:) > :) Is there a deeper reason why my mailbox should have 1777 
:) > :) protection?
:) >
:) > Yes, it has todo with sharing sessions with other programs that 
:) > access your mailbox (like the delivery program) or other clients that 
:) > you could use any other time to read your e-mail.
:) 
:) Thanks for this information. There are only two things I am still 
:) uncertain about:
:) 
:) I use Pine exclusively for my local IMAP service. IMAP takes care of 
:) locking. Because of this, I don't need the Pine locking mechanism, 
:) right?

Yes you do. You use it to protect yourself against the MDA. For example, 
if Pine is trying to expunge a message at the same time that the MDA is 
trying to add a message to the mailbox. There's great risk of corruption 
if you can not create a lock on the mailbox in this case.

:) Another strange thing: As soon as I start a 2nd Pine instance, I get a
:) 
:)     [{localhost}inbox : Trying to get mailbox lock from process 20648]
:) 
:) message, which does mean that there is a lock somewhere even though 
:) /var/mail is not 1777 protected (it is rwxrwxr-x with root.mail). Any 
:) idea where Pine gets this information from if there is no lock file?

Is it a hidden file in your /tmp directory.

Eduardo
http://www.math.washington.edu/~chappa/personal.html

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 10 Apr 2004 00:27:00 +0200 (CEST)

> if you can not create a lock on the mailbox in this case.

That must be a missunderstanding. If pine is using an IMAP server to
access the mail through, it will never read the inbox directly. That means
that pine will never need to do file locking. But of course, the IMAP
server must lock to avoid the collision that you describe.

> Is it a hidden file in your /tmp directory.

No, the lock file for the inbox (spool file) is created in the same
directory as the spool files.

Mats

---

From: Eduardo Chappa <[email-masked]>
Date: Fri, 9 Apr 2004 15:38:42 -0700 (PDT)

*** Mats Dufberg ([email-masked]) wrote on Apr 10, 2004:

:) On Apr 9, 2004, 15:02 (-0700) Eduardo Chappa 
:) <[email-masked]> wrote:
:) 
:) > :) I use Pine exclusively for my local IMAP service. IMAP takes care 
:) > :) of locking. Because of this, I don't need the Pine locking 
:) > :) mechanism, right?
:) >
:) > Yes you do. You use it to protect yourself against the MDA. For 
:) > example, if Pine is trying to expunge a message at the same time that 
:) > the MDA is trying to add a message to the mailbox. There's great risk 
:) > of corruption if you can not create a lock on the mailbox in this 
:) > case.
:) 
:) That must be a missunderstanding. If pine is using an IMAP server to 
:) access the mail through, it will never read the inbox directly. That 
:) means that pine will never need to do file locking. But of course, the 
:) IMAP server must lock to avoid the collision that you describe.

No it's not a misunderstanding, what happens is that the code that Pine 
uses to access local folders is the same as the imapserver uses to access 
the remote folder, so it does not matter if I say the word Pine or Server, 
it's the same situation.

:) > :) Another strange thing: As soon as I start a 2nd Pine instance, I 
:) > :) get a
:) > :)
:) > :)     [{localhost}inbox : Trying to get mailbox lock from process 
:) > :)     20648]
:) > :)
:) > :) message, which does mean that there is a lock somewhere even 
:) > :) though /var/mail is not 1777 protected (it is rwxrwxr-x with 
:) > :) root.mail). Any idea where Pine gets this information from if 
:) > :) there is no lock file?
:) >
:) > Is it a hidden file in your /tmp directory.
:) 
:) No, the lock file for the inbox (spool file) is created in the same 
:) directory as the spool files.

Read what I wrote again. I did not say that there was no lock on the 
spool, I said that there is a lock file in /tmp (which you should 
understand as a lock in addition to the lock in the spool), which locks 
c-client (the library used by Pine) against itself.

Eduardo

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 10 Apr 2004 00:57:44 +0200 (CEST)

> the remote folder, so it does not matter if I say the word Pine or Server,

Asuming that the IMAP server is the UW-IMAP server. -- If the pine is set
to read all mail from an IMAP server, it might not even be allowed to read
the files directly. It is the task of the IMAP server to take care of file
locking, not pine.

Pine shouldn't make any difference if the IMAP server is on the same
machine or a remote machine. Does it?

> c-client (the library used by Pine) against itself.

I believe you. :-)

So you say that pine will set lock files in /tmp when reading the INBOX
even if the INBOX is read from IMAP server? Even if the IMAP server is on
a remote machine? What is the purpose of that?

Mats

---

From: Eduardo Chappa <[email-masked]>
Date: Fri, 9 Apr 2004 16:14:54 -0700 (PDT)

:) On Apr 9, 2004, 15:38 (-0700) Eduardo Chappa 
:) <[email-masked]> wrote:
:) 
:) > :) That must be a missunderstanding. If pine is using an IMAP server 
:) > :) to access the mail through, it will never read the inbox directly. 
:) > :) That means that pine will never need to do file locking. But of 
:) > :) course, the IMAP server must lock to avoid the collision that you 
:) > :) describe.
:) >
:) > No it's not a misunderstanding, what happens is that the code that 
:) > Pine uses to access local folders is the same as the imapserver uses 
:) > to access the remote folder, so it does not matter if I say the word 
:) > Pine or Server, it's the same situation.
:) 
:) Asuming that the IMAP server is the UW-IMAP server. -- If the pine is 
:) set to read all mail from an IMAP server, it might not even be allowed 
:) to read the files directly. It is the task of the IMAP server to take 
:) care of file locking, not pine.
:) 
:) Pine shouldn't make any difference if the IMAP server is on the same 
:) machine or a remote machine. Does it?

That message is sent by the server. In this case the UW-IMAP server. 
That's the server that needs that protection to work (other servers may 
not). I am not making claims about other servers.

To put it again more precisely. There is a library called the c-client 
library, that library is used to write many programs, for example, Pine 
and the UW-IMAP server. Other programs that use c-client are rpdump, 
rpload, mtest, mailutil, ifrom, etc. If any of those programs access the 
spool directly (this means locally) and find that it is not protected 
1777, the program running the code will receive that message. That program 
may decide to pass the message to you or not. 

>From the perspective of the server the access is local, and this is the 
one that sends the message.

One way you can think about this is that it's c-client accessing the 
mailbox through the application (server, Pine, etc).

:) > :) > Is it a hidden file in your /tmp directory.
:) > :)
:) > :) No, the lock file for the inbox (spool file) is created in the 
:) > :) same directory as the spool files.
:) >
:) > Read what I wrote again. I did not say that there was no lock on the 
:) > spool, I said that there is a lock file in /tmp (which you should 
:) > understand as a lock in addition to the lock in the spool), which 
:) > locks c-client (the library used by Pine) against itself.
:) 
:) I believe you. :-)
:) 
:) So you say that pine will set lock files in /tmp when reading the INBOX 
:) even if the INBOX is read from IMAP server? Even if the IMAP server is 
:) on a remote machine? What is the purpose of that?

No, I say that any c-client aware program accessing locally the spool will 
create locks in its local /tmp. This means that the server will create 
locks in its local /tmp (or your remote /tmp). The lock file is a 0 byte 
hidden file. That's the reason why /tmp must also be protected 1777 in 
order to have c-client (server, pine, mailutil, etc) work locally.

As far as I undestand this is done to lock c-client aware applications 
against themselves (e.g. mailutil against Pine). In another words, 
c-client aware applications do not corrupt mailboxes when they work 
together.

I hope this makes more sense now.

Eduardo

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 10 Apr 2004 01:43:40 +0200 (CEST)

> may decide to pass the message to you or not.

Does that mean that UW-IMAP will pass the message to pine? Even if UW-IMAP
runs on remote machine?

> order to have c-client (server, pine, mailutil, etc) work locally.

OK, that means that pine will not create any lock files in /tmp if it
access mail through an IMAP server.

> I hope this makes more sense now.

It does.

As far as I have tested, pine will respect locking with fcntl done by the
delivery program, and also use such locking. Am I wrong?

Mats

---

From: Eduardo Chappa <[email-masked]>
Date: Fri, 9 Apr 2004 19:02:39 -0700 (PDT)

:) On Apr 9, 2004, 16:14 (-0700) Eduardo Chappa 
:) <[email-masked]> wrote:
:) 
:) > To put it again more precisely. There is a library called the 
:) > c-client library, that library is used to write many programs, for 
:) > example, Pine and the UW-IMAP server. Other programs that use 
:) > c-client are rpdump, rpload, mtest, mailutil, ifrom, etc. If any of 
:) > those programs access the spool directly (this means locally) and 
:) > find that it is not protected 1777, the program running the code will 
:) > receive that message. That program may decide to pass the message to 
:) > you or not.
:) 
:) Does that mean that UW-IMAP will pass the message to pine? Even if 
:) UW-IMAP runs on remote machine?

c-client produces the error, it hands it to the program that accessed the 
directory (the server in the remote case, Pine in the local case). In the 
case of the server, the server sends that message through the wire to 
Pine, which always passes warning messages to the users.

I've seen this message pass from the server to Pine before, I had to call 
the attention of the administrators about this immediately, and it was 
taken carevery quickly too.

:) > No, I say that any c-client aware program accessing locally the spool 
:) > will create locks in its local /tmp. This means that the server will 
:) > create locks in its local /tmp (or your remote /tmp). The lock file 
:) > is a 0 byte hidden file. That's the reason why /tmp must also be 
:) > protected 1777 in order to have c-client (server, pine, mailutil, 
:) > etc) work locally.
:) 
:) OK, that means that pine will not create any lock files in /tmp if it 
:) access mail through an IMAP server.

Correct, it will only do this for local access only. Just don't forget 
that it's not Pine, but c-client (through Pine) doing it.

:) > As far as I undestand this is done to lock c-client aware 
:) > applications against themselves (e.g. mailutil against Pine). In 
:) > another words, c-client aware applications do not corrupt mailboxes 
:) > when they work together.
:) >
:) > I hope this makes more sense now.
:) 
:) It does.
:) 
:) As far as I have tested, pine will respect locking with fcntl done by 
:) the delivery program, and also use such locking. Am I wrong?

No, you are right.

Eduardo