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

[Sam Roberts]

Quoteing address@hidden, on Fri, Mar 22, 2002 at 01:58:05PM +0200:
> > I don't know anything about the other namespace, particularly. What's
> > the setup?
> 
> Well, basically, imap4d allows to access mailboxes in three separate
> namespaces: a) user's private namespace, where the user usually has
> all the rights over the files, b) shared namespace, which may or may
> not be writable by the user and c) other namespace, which is generally
> not writable neither for the user nor for the group. The setup is
> described in detail in RFC 2342. The problem arises when imap4d is
> trying to open (and consequently lock) a mailbox which is located
> in other (and sometimes in shared) namespace.

On reconsidering, I've a few more questions.

The external locker is setgid mail, so it can create lock files in
/usr/spool/mail when:

rwxrwxr-x  root mail /usr/spool/mail
rw-------  sam  users /usr/spool/mail/sam

If you want to lock files in a directory that group mail doesn't have
write access, the external dotlock won't help you, and will be slower.

I could make the external locker setuid root.

Is there a way for imap4d to gain uid root back again, so it can
lock anything, anywhere? I'm having a hard time wrapping my head
around the uid/euid/saved-uid relationships, I'll keep staring.

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 do you think?

Sam

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