[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sam Roberts
Subject: Re: Added ~/.<program>rc as a config file.
Date: Wed, 27 Mar 2002 21:48:51 -0500
User-agent: Mutt/1.3.16i

Quoteing address@hidden, on Wed, Mar 27, 2002 at 11:44:23PM +0200:
> > 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.
> > 
> Actually, this is how imap4d() operates now. But selecting and locking
> of a mailbox takes place after switching to the user privileges.

Sorry, you are correct, of course. I thought it didn't do this because
my spool was at one time writeable only for root, which was causing
the daemons to NOT be able to lock in it. Now I see what was happening.
My mistake.

Perhaps the daemons could set their group to the group of the spool
directory? Is this too weird?

> > 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
> Not exactly. I didn't explain myself well, the first line in the
> algorythm should have read:
> > 1.   If the mailbox about to be locked is writable at the current
> >      privilege level, then:
> If the spool is writable only by group mail, we will still be able to
> create lockfile there ("we" means here pop3d and imap4d):
> imap4d switches to group 'mail' after startup. When switching to
> user privileges, it does setuid, but does not change its gid,
> so it remains at 'mail' gid. Pop3d operates in the similar manner.
> So, the current gid is always that of 'mail'.
> > 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?
> Sure, seeing how others do a task is always a good idea. Anyway,
> please give the proposed scheme your consideration.

Ok, it sounds reasonable for utilities run by the system. I'll work
on it.

For utilities run by the user, I think the default should include attempting
to lock with the external setgid dotlock utility before dropping down to
fcntl/flock locking. Seem sensible?

I'll summarize this algorithm before implementing it, but not tonight.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]