Man, I go out of town for a few days and a whole bunch of stuff gets
said on this topic. Responding to various emails ...
I can not think of one reason why inc shoud be set{g,u}id'ed.
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).
I often switch to another user to see if they've any new email they'd
like to know about. All I really need for that is setuid inc that scans
the From and Subject fields.
I mean, the -file switch exists for a reason; we're just arguing about
the defaults. But if you 'su' to that person the real UID will be set
to the target user.
Also, both the other user and I have already acknowledged the 1.7+dev
welcome message, yet it is shown again.
Well, I've run into THAT bug before. If the context file isn't updated
(e.g.,, if there is an error) then the right magic isn't written out to
it. And not all commands update the context file either.
But even though the person who did this had su'd to root, some of
their user environment variables were inherited by their root shell
and then inherited by inetd
That sounds like user error; they ran `su' rather than the more commonly
wanted `su -'. Similarly today, `sudo -i'.
Well, I mean ... yeah, but it was hard to make the argument that those
network daemons were SUPPOSED to behave that way if those environment
variables were in their environment. Those SE's had "su" wired into
their brains. (I believe fixing in the code was really a matter of
changing the last argument of setenv() to "1" and it was hard to
argue that it shoudn't have been that way from the start).
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.
Secondly, I guess it all boils down to the semantics of the real and
effective userids. My understanding is the real uid is supposed to
indicate the "real" user sitting at the keyboard (ok, fine, it's not
clear what THAT means nowadays, but pretend that we're not going to
argue about that). And I kind of thought we were all on the same
page about that since a number of people suggested using getlogin()
or LOGNAME to determine the default maildrop name; my only concerns
with that was that it was a change to the default behavior and we had
no guarantees that it worked everywhere and one of the lesson WE KEEP
LEARNING with (n)mh is: "think carefully about unintended consquences".
My understanding is that when the effective uid is different than the
real uid is that you are in a special privilege escalation state, you
should keep the escalated privileges only as long as you need them
and give them up when you are done. So given all of that it strongly
suggests to me that the default maildrop name should be based on the
real uid (like it is now). I'm willing to hear arguments to the contrary,
but I think given a) the long history of this behavior and b) the fact
you can override all of this behavior from the inc(1) command line
means a very strong case is going to have to be made for a change.
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers