From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5216 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 1.0.x branch Date: Tue, 10 Jun 2014 12:03:56 -0400 Message-ID: <20140610160356.GL179@brightrain.aerifal.cx> References: <20140606175617.GA3914@brightrain.aerifal.cx> <20140609112352.1e7ad51e@ncopa-desktop.alpinelinux.org> <20140609200830.GK179@brightrain.aerifal.cx> <20140610094351.GE20596@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1402416268 32538 80.91.229.3 (10 Jun 2014 16:04:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Jun 2014 16:04:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5221-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 10 18:04:21 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WuOX4-0004ia-4s for gllmg-musl@plane.gmane.org; Tue, 10 Jun 2014 18:04:18 +0200 Original-Received: (qmail 7203 invoked by uid 550); 10 Jun 2014 16:04:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7173 invoked from network); 10 Jun 2014 16:04:09 -0000 Content-Disposition: inline In-Reply-To: <20140610094351.GE20596@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5216 Archived-At: On Tue, Jun 10, 2014 at 11:43:51AM +0200, u-igbb@aetey.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@localhost". :-) > 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