> Several people have asked about the costs and benefits of splitting a
> setuid program into an unprivileged user process and a non-setuid
> daemon.
> C=08Co=08os=08st=08ts=08s.=08. [...]
[For those who don't feel like working it out, that's "Costs." with
quoted-printable backspaces attempting overstrikes.]
Your bias is showing. You're missing a cost: the program doesn't work
if the daemon isn't running. (For whatever reason: single-user, it
crashed, etc.) You're missing another cost: convincing some
appropriate "kernel implementor" to provide getpeereuid(). (It's not
just a matter of doing it - for OSes less into the kitchen-sink
philosophy than Linux, there's the question of whether that's the right
way to go - and even if it does go in, I think your "five minutes" is
grossly optimistic, especially when you add regression testing,
documentation, maintenance, etc, etc.)
> It shouldn't take more than five minutes for a kernel implementor to
> support getpeereuid(). For example, Linux has "struct ucred
> peercred" inside struct sock,
A peer credentials structure in every socket, just to support AF_LOCAL
credentials? I'd say this belongs in (the Linux analog of) the struct
unpcb. (Not that Linux cares what I think. :-)
der Mouse
mouseat_private
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:24 PDT