Re: Added ~/.<program>rc as a config file.

[Sam Roberts]

Quoteing address@hidden, on Mon, Mar 25, 2002 at 12:19:04PM +0200:
> Bonjour
> 
> > Is there a way for imap4d to gain uid root back again, so it can
> > lock anything, anywhere?
> 
> No, there is not. It uses setuid which makes re-gaining root
> privileges impossible. It could be changed, but I wouldn't like
> changing it, due to the security reasons.

As I think about it, we don't have to regain root, we just have to be able to
access the spool. And we'd like to not be root, but who we are doesn't matter
that much, as long as they don't have a lot of priviledges.

So how about we do this:

  - Start as root, change to the group of the spool directory, so we can lock it
    (or just to "mail", or a config option).
  - Change to the user id of the user, so we can access their mailbox.

This seems minimally priviledged.

Do you think something along those lines might work?

> > What I don't like about the "lock in another directory", is that
> > it doesn't seem interoperable, wouldn't somebody with permissions
> > locking the file with some other tool create a "real" lockfile? It
> > seems fragile.
> 
> What's more: a conflict arises while locking two different mailboxes
> having the same names but residing in different directories. There
> are other problems too. On reconsidering, I do not regard this method
> as a reliable one, either.

> > What do you think?
> 
> I would propose the following way of applying a write lock:
> 
> 1.   If the mailbox about to be locked is writable for the current user, then:
> 1.1    If the directory it resides in is also writable then
> 1.2      lock it as usual.
> 1.3    otherwise
> 1.4      fall back to lockf (or fcntl) file locking.
> 2    otherwise
> 2.1    do not lock it at all.   
> 
> Opinions?

I guess I don't know what most people do, but I'm under the impression
that most systems set the spool to be writeable only by group mail.
So, I think we will almost always hit case 1.4

But if most client programs don't use file locking, or file locking
is buggy, we won't interoperate.

Just speculation, I don't really know what other programs do. Perhaps
we can collect some information on how others do it, and pick this up
again in a month?

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)