Re: musl 1.0.x branch

[u-igbb@aetey.se]

Hello Rich,

On Tue, Jun 10, 2014 at 12:03:56PM -0400, Rich Felker wrote:
> > We do not use setuid applications (considering them harmful for a number
> > of reasons).
> 
> No disagreement here. I'm the one who recommends alias su="ssh
> root@localhost". :-)

:)

> For at least some of these (hosts and resolv.conf) I'd really like to
> provide a way for users to override them at runtime. This is important
> for testing and merely a matter of reasonable user convenience. But I
> don't have a good idea for how to do it yet without various issues. :(

> My feeling is that I want it to be "mildly hard by default" to change
> these things and maintain the changes, since a lot of users will do it
> without understanding the consequences. Especially when multiple

I understand your concerns and yes each extra "degree of freedom" is risky
especially when the concerned parties do not really know how to handle it.

On the other side a switch like
 --I-really-know-what-I-am-doing-and-why=env-db-redirection-never-ever-suid
makes a feature quite hard to choose without thinking at least a second :)

> BTW if you could fully turn off suid at the kernel level, patching the
> kernel to allow normal users to use mount namespaces and bind mounts
> would be a great way to allow the kind of flexibility you want
> globally (not just in libc) without any patching in userspace.

What you suggest would be a redesign of the API, with yet not fully clear
possibilities and consequences. This would also imply a new special way
to administer hosts running such a kernel.

Unfortunately this would not be sufficient for the purposes I think of.

Our software is directly runnable on any host with e.g. a Linux-compatible
ABI (or otherwise Posix-compatible API), _independently_ [sic] of how the
host is administrated. We do not rely on any tweaks on the "host" level.
(The only prerequisites are the availability of a file system with
a global name space (like Coda, AFS, DCE/DFS) and allowed execve())

The user-space-based tweaks are conforming to Posix in any aspect -
besides the no longer hardcoded database references, different if
and only if the party running the application wants to redirect them.
Such a redirection does not need to involve kernel at all, the namespace
changes are not relevant to the kernel nor to any other party.

> > Another change we opted to do is switching off any and all rpath
> > interpretation, which corresponds to our software maintenance routines
> > and makes it easier and safer for us. The less constraints are hardwired,
> > the better we can use the software.
> 
> Is there a reason this is needed, rather than just refraining from
> using them in your builds? -rpath with $ORIGIN seems like an easier
> way to achieve some of the things you want.

Unfortunately rpath even with $ORIGIN is not quite up to the task,
I think I mentioned this earlier.

Besides not being sufficient, it imposes restrictions and hence is
undesirable. (Many compilation scripts yet try to enforce it - this
is easy to miss which then leads to unexpected aka broken behaviour
at runtime.) That's why we disallow all forms of rpath in the loader.

IOW we do not need, nor _want_ constraints on the absolute or relative
placement of binaries and libraries.

Using standalone loader and explicit --library-path meets the actual
needs without adding constraints: we can freely combine the binaries
and the libraries without recompilation (and say without copying the
binary to be able to create a certain combination of libraries by putting
them "side-by-side" or whatever is in $ORIGIN)

_Possibly_ one might construct a system similar (?) to ours but with
a rpath-based design. In reality noone has come up with any working
solution, besides ours. So while academically "what could work" or "what
would work best" it is an open question, practically there is no other
working global design.

So for the purposes of global software placement you can calmly count
Aetey to be the host of _the_ implementation :)

> 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

Surely we are aware of this model being superior to suid - when necessary.

Nevertheless, many of the cases where suid is being used are just due
to mistakes in the very logic of the design.

E.g. you do not need a suid helper (nor a daemon) to use PAM for your
screensaver lock (the password hash does NOT have to be in "the"
root-owned shadow file, nor do you need to check a Kerberos ticket
against "the" root-owned keytab - the secrets belong to the security
domain which they are to protect, in this case the security domain is
not the host but the _user_ session).

We solve this pretty straightforwardly by using environment variables,
pointing to a relevant "shadow" file and/or pam configurations.

> 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).

You see, we often do not even have to rely on a single extra process
with elevated privileges :)

Thanks for taking my suggestions seriously. As I said I do not really
expected much attention/support for our "unusual" usage pattern but I hope
you see some sense in our approaches and in our reasoning.

Regards,
Rune