Re: Wiping out setuid programs

[mouse () RODENTS MONTREAL QC CA (der Mouse)]

> 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

                               mouse () rodents montreal qc ca
                     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B