Re: musl 1.0.x branch

[Rich Felker <dalias@libc.org>]

On Tue, Jun 10, 2014 at 05:50:51PM +0100, Laurent Bercot wrote:
> On 10/06/2014 17:03, Rich Felker wrote:
> 
> >FYI you can emulate the usefulness of suid, without the danger, by
> >having a daemon on a unix socket that you connect to which provides
> >the functionality. This is a vastly superior design because there is
> >exactly one input channel to the code running with elevated privileges
> >(the socket) as opposed to unboundedly many (environment, open fds,
> >resource limits, working directory, priority, signal mask and
> >dispositions, cpu affinity, ... and whatever else the kernel folks add
> >in the future).
> 
>  And now there are even programs designed to help you do exactly that:
>  http://skarnet.org/software/s6-networking/s6-sudo.html
>  (Shameless plug of the day: achieved)
> 
>  However, despite being a good solution for noninteractive programs, the
> unix socket mechanism isn't perfect. There are a lot of things it cannot
> transmit without significant trouble - in particular terminals and
> everything job-control-related, and signals, etc. I've done quite a bit
> of thinking while writing s6-sudo, and my conclusion was that it's a
> daunting task to get everything working properly with programs that
> need a terminal; it would require ugly wrappers à la ptyget, and more.
> I'm not convinced it's even worth trying, as opposed to tackling the
> existing terminal-using privilege-granting programs and kicking the
> suid out of them.

Sending the terminal fd over a socket with SCM_RIGHTS isn't
sufficient? If the privileged process has root, it should be able to
add itself to the process group of the client so that job control,
terminal signals, etc. work right.

Of course from a security standpoint it's better to put the UI that
uses the terminal in the client-side anyway, and limit the amount of
logic in the privileged server-side, but this is a good deal of extra
refactoring/redesign work if you have legacy applications.

Rich