[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.
Cheers,
Sam
--
Sam Roberts <address@hidden> (Vivez sans temps mort!)
- Re: Added ~/.<program>rc as a config file., (continued)
- Re: Added ~/.<program>rc as a config file., Sam Roberts, 2002/03/20
- Re: Added ~/.<program>rc as a config file., Sergey Poznyakoff, 2002/03/21
- Re: Added ~/.<program>rc as a config file., Sam Roberts, 2002/03/21
- Re: Added ~/.<program>rc as a config file., Sergey Poznyakoff, 2002/03/22
- Re: Added ~/.<program>rc as a config file., Sam Roberts, 2002/03/23
- Re: Added ~/.<program>rc as a config file., Sam Roberts, 2002/03/24
- Re: Added ~/.<program>rc as a config file., Sergey Poznyakoff, 2002/03/25
- Re: Added ~/.<program>rc as a config file., Sergey Poznyakoff, 2002/03/25
- Re: Added ~/.<program>rc as a config file., Sam Roberts, 2002/03/27
- Re: Added ~/.<program>rc as a config file., Sergey Poznyakoff, 2002/03/27
- Re: Added ~/.<program>rc as a config file.,
Sam Roberts <=