[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140610160356.GL179@brightrain.aerifal.cx>
Date: Tue, 10 Jun 2014 12:03:56 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl 1.0.x branch
On Tue, Jun 10, 2014 at 11:43:51AM +0200, u-igbb@...ey.se wrote:
> On Mon, Jun 09, 2014 at 04:08:30PM -0400, Rich Felker wrote:
> > Having a rolling
> > "well-tested and believed stable except for known bugs X, Y, and Z"
> > release that's a few versions behind the latest release, and a list of
> > commits since then which are purely bug-fixes, might be a good
> > practical option. Such pairs of (base-version,list-of-commits) could
> > automatically be transformed into tarballs.
>
> This looks good and makes sense.
>
> Despite not having other maintenance-related thresholds
> we maintain some local patches and it is easier to apply them
> when the changes inside the codebase are limited.
>
> Slightly offtopic:
>
> Of course an even better solution would be to have a somewhat
> stable "interface" for applying changes important to us.
>
> 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@...alhost". :-)
> This makes it possible and quite desirable to be able to control certain
> properties of the library at run time. We let a deployment administrator
> choose e.g. which name services and authentication means are to be used
> for a certain instance of the application - using environment variables
> pointing to dedicated hosts/resolv.conf/passwd/group/shadow/pam.d
> and similar.
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. :(
> So if musl would have any kind of hooks to implement this (as a
> compilation option or say by a convention which would make it easier to
> apply patches without rereading/rechecking all the source) it would be
> highly valuable.
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
distributions are in the process of adopting musl or adding musl-based
variants, it's a real liability with regards to how people perceive
musl if distributions have gratuitously modified paths such that
binaries from one don't work on another. Certainly we can't stop it,
but not doing the work for them at least gets people thinking about
doing it to stop and ask so we can mention the cons of doing so.
I don't think I'm just making up this concern; we already had it with
at least one or two distro packagers changing the location PT_INTERP
points to (the --syslibdir) and the change was simply a
misunderstanding of requirements that was fixed once it was discussed.
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.
> I understand that this is unconventional and do not expect much of
> attention but at least it is worth to name that such a need exists.
>
> 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.
> (Of course these changes are totally incompatible with the traditional
> usage of a "general purpose C library" which is shared between both
> non-setuid and setuid applications. To the contrary, different kinds
> of applications here get different kinds of the library/ies so that we
> would not be stuck even if we discover that we badly need setuid in a
> certain case)
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).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
