From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5224 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 17:51:56 -0400 Message-ID: <20140610215156.GO179@brightrain.aerifal.cx> References: <20140606175617.GA3914@brightrain.aerifal.cx> <20140609112352.1e7ad51e@ncopa-desktop.alpinelinux.org> <20140609200830.GK179@brightrain.aerifal.cx> <20140610094351.GE20596@example.net> <20140610160356.GL179@brightrain.aerifal.cx> <20140610203247.GG20596@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 1402437303 15673 80.91.229.3 (10 Jun 2014 21:55:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Jun 2014 21:55:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5229-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 10 23:54:56 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 1WuTxi-0005zs-Jy for gllmg-musl@plane.gmane.org; Tue, 10 Jun 2014 23:52:10 +0200 Original-Received: (qmail 30431 invoked by uid 550); 10 Jun 2014 21:52:09 -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 30420 invoked from network); 10 Jun 2014 21:52:09 -0000 Content-Disposition: inline In-Reply-To: <20140610203247.GG20596@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5224 Archived-At: On Tue, Jun 10, 2014 at 10:32:48PM +0200, u-igbb@aetey.se wrote: > > 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 :) Sadly, I really doubt it does; it comes across as patronizing, which annoys users with an "I know what I'm doing!" attitude. In any case, it's also a matter of maintenance cost. Supporting environment variables to override these things is not always trivial. Some (most?) of these interfaces are required to be thread-safe and accessing the environment is not thread-safe with respect to other threads modifying it. There may also be storage/allocation burdens when allowing a custom runtime path requires concatenating it with another string. Even if none of this were difficult, it's extra combinatorics for testing, and that issue was basically uclibc's demise. In the long term there may be ways we could change things upstream to make it easier to maintain your changes -- for instance, replacing the inline string literals with references to symbols. You could then replace the const arrays the symbols refer to with non-const arrays that get filled in at program startup (this is probably a lot safer than calling getenv on demand, albeit slightly more bloated). > > 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()) *nod* It's a shame this option isn't available in mainline kernels though. It would be really nice if any user could do bind mounts with a local fs/mount namespace and if doing so just precluded the suid bit from taking effect in affected processes. > > 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. Note that the "tcb shadow" support in musl already provides this functionality. For your purposes, of course, you already have path override so it makes sense just to use the same tool you're using for everything else. But for other uses outside yours, tcb shadow is a really nice solution to this problem. > > 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. Yes, it makes sense. Rich