Date: Sun, 09 Jun 2019 20:04:53 -0400
From: Ken Hornstein <kenh@pobox.com>
Message-ID: <20190610000454.EBC8A15C7E9@pb-smtp2.pobox.com>
| Secondly, I guess it all boils down to the semantics of the real and
| effective userids.
Not entirely, but that's part of it.
| My understanding is the real uid is supposed to
| indicate the "real" user sitting at the keyboard
No, that's not it (and the questions of what the keyboard or "sitting at"
might mean has nothing to do with it). The real user id is the id of the
user who caused the command to be executed (or in some cases, the
sequence of commands). The effective user id is the id whose privs
are to be used while running the command. (Most of the time, of
course, they're the same).
Neither of those has anything in particular related to who "logged in"
(if anyone did) -- except that both of those users needed, at some time
in the past to have interacted with the system to set up, or commence,
the sequence involved.
In all of this the "user" is a virtual thing, whose relationship with
any particular human is tenuous at best (almost any kind of mapping
can exist).
How anything like communication with a particular human (which e-mail
is generally assumed to accomplish) is made to work in this environment
is something of a miracle (and a whole bunch of happenstance and chance).
| 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.
escalation is the wrong word, modification might be better - we generally
think of it as escalation, as the most common effective uid is 0 (root)
which is an escalation, but it need not be - commands can be setuid to
nobody (the user name, I don't mean the antonym of anyone) which is
almost never any kind of escalation.
But otherwise approximately right .. though sometimes the effective user
(which has the perms) decides to also become the real user and continue
that way, that's what su/sudo do - so it isn't always just access some
file (or create a socket, ...) and then revert to the real user.
| 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 doubt that the effective uid is the answer, that I agree with.
I really cannot imagine a sane modern use case for having inc setuid, or
invoking it from a setuid command that has not make real==effective
before invoking it though ... I'd suggest that anyone in this day
and age who makes inc setuid (or runs it so that it is) deserves
whatever bogus behaviour comes their way (long, long, long, ago it
was necessary on some systems, for the same reason setgid has sometimes
more recently been used - except before anyone had thought of having
a group "mail" and simply had the maildrop directory only writeable by
root.)
kre
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers