Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.

[Ralph Corderoy]

Hi Ken,

> In the "old days", it was common for the mail spool to only be
> writable by group 'mail' (or something similar) and if you did dot
> locking you couldn't create a lock file in the spool directory unless
> your mail program was setgid mail (you can see this code in the
> original MH).

Doesn't nmh still do this, e.g. configure may define MAILGROUP?

> > Regardless of whether it's a good idea, since the kernel is using
> > effective user and group IDs for testing permissions, if a user ID
> > is used to determine what files to access then it should be the
> > effective one rather than the real one.  Do you agree?
>
> Well ... no, not in this case.
>
> First, I do wonder what you think you're accomplishing by making
> inc(1) setuid; we don't do any of the right stuff in terms of changing
> the effective userid BACK when writing out the messages.

And I wouldn't want it to.  If setuid to foo then I'd expect user foo's
mail spool to be read, and its +inbox to be written, all based on its
.mh_profile.  But inc is a distraction.

As I said originally, that everyone ignored and just replied about inc
:-), this is Unix and file stuff where the kernel is using the euid
should be paired with userspace using the euid, e.g. don't attempt to
read my file with your permissions.  If we want to document nmh can't
run setuid or setgid, apart from explicit exceptions, then that's fine,
but at the moment it doesn't say that and actively codes for those
cases, e.g. environment variable MHTMPDIR is ignored if either setuid or
setgid.

-- 
Cheers, Ralph.