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.
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers