From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5220 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 1.0.x branch Date: Tue, 10 Jun 2014 22:32:48 +0200 Message-ID: <20140610203247.GG20596@example.net> 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> 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 1402432402 13202 80.91.229.3 (10 Jun 2014 20:33:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Jun 2014 20:33:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5225-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 10 22:33:16 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 1WuSjL-00081a-82 for gllmg-musl@plane.gmane.org; Tue, 10 Jun 2014 22:33:15 +0200 Original-Received: (qmail 22148 invoked by uid 550); 10 Jun 2014 20:33:14 -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 22140 invoked from network); 10 Jun 2014 20:33:14 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe09.swip.net; client-ip=64.113.44.206; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140610160356.GL179@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5220 Archived-At: 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