From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4342 Path: news.gmane.org!not-for-mail From: Raphael Cohn Newsgroups: gmane.linux.lib.musl.general Subject: Re: _PATH_LASTLOG Date: Tue, 3 Dec 2013 20:49:32 +0000 Message-ID: References: <20131203184248.GT1685@port70.net> <20131203195433.GM24286@brightrain.aerifal.cx> <20131203202502.GO24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1134a71af7c39704eca76e2d X-Trace: ger.gmane.org 1386103778 1373 80.91.229.3 (3 Dec 2013 20:49:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2013 20:49:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4346-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 03 21:49:45 2013 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 1Vnwuf-0004HP-JV for gllmg-musl@plane.gmane.org; Tue, 03 Dec 2013 21:49:45 +0100 Original-Received: (qmail 28372 invoked by uid 550); 3 Dec 2013 20:49:45 -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 28364 invoked from network); 3 Dec 2013 20:49:44 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=EYSeMkPrYIl+ZZC1xJj2hAUKgttn9XAQpFqnzC1U4X4=; b=ZYZC0Ef3cvF6fZTEwlC4V6ZZOyjwqqolShyackMJijglCphf2F4q9+yRmL0VJKLFoD ZKNQA+OG7yubnkXlVvJr1nsfi76gpkfqYy2pBJC/fKWgb3YPUKzag9EM8dmKORs/VHUm xokqHtOxAmDMEBZekDrimVU1xN5yw74YHupT+bajpCape43E7+2yR6/M3jWhmLSy7FCh hF1pmj82KXjpT0wlrx9KI4b4CUi9yD0lXv7lcZigsmKV4B+2Oeta1qt5OtiEB9sJEUA+ L2xI7i0g2P8y5nsBME+jwXbuhsAE1tC2OoXMzgWjWpemxX1/JHvxkvdDVxe2FwABodj/ TuUA== X-Gm-Message-State: ALoCoQka7wWakYgO2yhlExtznMRpmVfSqbDsQVq3bTfihHUY856ctPi/ItcsQ0NGZ4TruUfzUpx+ X-Received: by 10.182.255.137 with SMTP id aq9mr1187536obd.80.1386103772262; Tue, 03 Dec 2013 12:49:32 -0800 (PST) X-Originating-IP: [2001:8b0:862:b944:a534:c887:3b4d:f028] In-Reply-To: <20131203202502.GO24286@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4342 Archived-At: --001a1134a71af7c39704eca76e2d Content-Type: text/plain; charset=UTF-8 Q: Are you also talking about having separate configuration dirs... Actually, not quite, but that also sounds like a very interesting idea with a lot of potential. I suspect one needs to be careful that it wouldn't then be possible for a nasty binary to define its own path, to say, password, and allow it to be overridden. I'm thinking LD_LIBRARY_PATH here. (Actually, it might be a good idea to be able to disable that inside the libc for some set-ups). What I'm thinking about is a system reconfiguration. When it's ready (packages compiled, etc changes made, and so on), one flips a symbolic link. Something we are toying with is 'what is config'. Some config really isn't - once you have a source controlled, rebuildable system, there's no point having a special /etc any more. In practice, not everything in /etc is actually config. Some things are actually writable (eg the OATH Toolkit's PAM does this). Some things never change unless the packages change, And a few small things need to change occasionally. Such as users. But even then, with most modern servers that actually only have a few admins, that can be managed by package rebuilds... Q: Nixos... It's clever, but there's too much CompSci. The scripting language is impressive but hard for sysadmins. What's more interesting is a build system based around the lowest common denominator that's workable. Bash is our current choice. We'd like to go ash, but fundamental things (eg support for reading \0 delimited data for security when parsing file lists) isn't supported. Q: Philosophy That'd go nicely in the wiki or the website! I've not got much problem using a local daemon. We're probably adopt a variant of dnsmasq for what we need to do. Personally, I loathe NSS and NIS and that world, but there you go, it's out there and its used. The downside is that sloppy programming propagates. Really, most DNS lookups should be unified and use SRV records (or MX for a specialised use case) and DNS Sec, but that's hard to do and if the library's not on the box, it doesn't happen. Raphael Cohn Chief Architect, stormmq Co-Chair, OASIS MQTT Standard Secretary, OASIS AMQP Standard raphael.cohn@stormmq.com +44 7590 675 756 UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 3 December 2013 20:25, Rich Felker wrote: > On Tue, Dec 03, 2013 at 08:10:56PM +0000, Raphael Cohn wrote: > > Thanks for that - just having a list is an useful place to start. I think > > the default file names are quite sensible - especially for a common > > run-anywhere use case. And some - where mandated by POSIX - probably > should > > never change. What would be nice might be to be able to define the prefix > > for /etc to something else (so we can use atomic symlink changes to flip > > configs). > > Are you also talking about having separate configuration dirs for each > package? Would each package need its own user database (passwd file), > DNS configuration (which the DHCP client would have to update), etc.? > The intent in musl is that the "config"-like files it reads from /etc > are not things that should be application-local but system-global. > Obviously there are different views on what's local/global, though. > One problem I'd like to solve is making a way for users to override > the system resolv.conf; this would be especially valuable for us (musl > developers) writing test cases for the resolver, in that we could > redirect lookups to a fake DNS daemon running in a separate thread of > the test program serving fixed, possibly-intentionally-malformed > replies. > > > I'd like to have more of a think about the other paths. We're only a > short > > way into our project, so our ideas might change. What we're looking at > is a > > Nixos-like linux, where we rebuild only packages because other packages > > have changed. We want to keep every package isolated, so we can apply > PATH > > controls, fine-grained capability permissions, chattr -ai, etc. Part of > > doing this means we don't want paths 'hanging around' inside libraries > that > > are used if present - as these allow an attacker (or more likely, a duff > > package) to accidentally stop itself working, ie if there's no /usr/lib > on > > system, then nothing should be able to stick itself in /usr/lib and > > override the system setup. > > This seems like a good foundation for a package system. I've looked > into Nixos before but never really tried it out, and got the > impression that the concept was very good but it might not be the best > implementation. So something similar to Nixos sounds interesting. :-) > > > PS As an aside, I've always wanted /etc/hosts to also have a parallel > > /etc/hosts.d/. It'd make maintaining things without a DNS server > extremely > > easy - think dynamically adding and removing VMs in most cloud providers, > > especially those where multicast DNS doesn't work... like Azure. (Yes, I > > had a client that insisted on using it with Linux). Likewise it'd be nice > > to be able to add and remove DNS servers with a /etc/resolv.conf.d. Makes > > automated config and change management and audit that bit easier. (Debian > > do this using run-parts for lots of things for those sorts of reasons). > > The philosophy used in musl, which is somewhat different from the sort > of philosophy you might have when designing a new distribution, is not > to invent new policy but to avoid policy and build on existing, > already-widely-accepteed policy when it's unavoidable. There are LOTS > of ways one could extend hostname lookups, ranging from NSS modules to > hosts.d and resolv.d, but rather than trying to support everything > imaginable (result: bloat and serious security considerations) in > libc, the musl approach to hostname lookup is that libc contains the > basics that are suitable for most/all simple systems, and anything > more advances can be provided by an external daemon running on > localhost that speaks DNS protocol and provides whatever lookup > semantics you desire. > > Rich > --001a1134a71af7c39704eca76e2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Q: Are you also talking about having separa= te configuration dirs...

Actually, not quite, but that also so= unds like a very interesting idea with a lot of potential. I suspect one ne= eds to be careful that it wouldn't then be possible for a nasty binary = to define its own path, to say, password, and allow it to be overridden. I&= #39;m thinking LD_LIBRARY_PATH here. (Actually, it might be a good idea to = be able to disable that inside the libc for some set-ups).

What I'm thinking about is a system reconfiguration. Whe= n it's ready (packages compiled, etc changes made, and so on), one flips= a symbolic link.

Something we are toying with is 'what= is config'. Some config really isn't - once you have a source cont= rolled, rebuildable system, there's no point having a special /etc any = more. In practice, not everything in /etc is actually config. Some things a= re actually writable (eg the OATH Toolkit's PAM does this). Some things= never change unless the packages change, And a few small things need to ch= ange occasionally. Such as users. But even then, with most modern servers t= hat actually only have a few admins, that can be managed by package rebuild= s...

Q: Nixos...
It's clever, but there's t= oo much CompSci. The scripting language is impressive but hard for sysadmin= s. What's more interesting is a build system based around the lowest co= mmon denominator that's workable. Bash is our current choice. We'd = like to go ash, but fundamental things (eg support for reading \0 delimited= data for security when parsing file lists) isn't supported.

Q: Philosophy
That'd go nicely in the wiki= or the website! I've not got much problem using a local daemon. We'= ;re probably adopt a variant of dnsmasq for what we need to do. Personally,= I loathe NSS and NIS and that world, but there you go, it's out there = and its used.

The downside is that sloppy programming propagates. Really, most = DNS lookups should be unified and use SRV records (or MX for a specialised = use case) and DNS Sec, but that's hard to do and if the library's n= ot on the box, it doesn't happen.


Raphael Cohn
Chief Architect, stormmq
Co-Chair, OASIS MQTT St= andard
Secretary, OASIS AMQP Standard
raphael.cohn@stormmq.com
+44 7590 675 756

UK Office:
Hamblethorpe Farm, Crag = Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom
Telephone: +44 8= 45 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, U= nited Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 071= 75657
StormMQ.com


On 3 December 2013 20:25, Rich Felker <= dalias@aerifal.cx> wrote:
On Tue, Dec 03, 2013 at 08:10:56PM +0000, Raphael Cohn wr= ote:
> Thanks for that - just having a list is an useful place to start. I th= ink
> the default file names are quite sensible - especially for a common > run-anywhere use case. And some - where mandated by POSIX - probably s= hould
> never change. What would be nice might be to be able to define the pre= fix
> for /etc to something else (so we can use atomic symlink changes to fl= ip
> configs).

Are you also talking about having separate configuration dirs for eac= h
package? Would each package need its own user database (passwd file),
DNS configuration (which the DHCP client would have to update), etc.?
The intent in musl is that the "config"-like files it reads from = /etc
are not things that should be application-local but system-global.
Obviously there are different views on what's local/global, though.
One problem I'd like to solve is making a way for users to override
the system resolv.conf; this would be especially valuable for us (musl
developers) writing test cases for the resolver, in that we could
redirect lookups to a fake DNS daemon running in a separate thread of
the test program serving fixed, possibly-intentionally-malformed
replies.

> I'd like to have more of a think about the other paths. We're = only a short
> way into our project, so our ideas might change. What we're lookin= g at is a
> Nixos-like linux, where we rebuild only packages because other package= s
> have changed. We want to keep every package isolated, so we can apply = PATH
> controls, fine-grained capability permissions, chattr -ai, etc. Part o= f
> doing this means we don't want paths 'hanging around' insi= de libraries that
> are used if present - as these allow an attacker (or more likely, a du= ff
> package) to accidentally stop itself working, ie if there's no /us= r/lib on
> system, then nothing should be able to stick itself in /usr/lib and > override the system setup.

This seems like a good foundation for a package system. I've look= ed
into Nixos before but never really tried it out, and got the
impression that the concept was very good but it might not be the best
implementation. So something similar to Nixos sounds interesting. :-)

> PS As an aside, I've always wanted /etc/hosts to also have a paral= lel
> /etc/hosts.d/. It'd make maintaining things without a DNS server e= xtremely
> easy - think dynamically adding and removing VMs in most cloud provide= rs,
> especially those where multicast DNS doesn't work... like Azure. (= Yes, I
> had a client that insisted on using it with Linux). Likewise it'd = be nice
> to be able to add and remove DNS servers with a /etc/resolv.conf.d. Ma= kes
> automated config and change management and audit that bit easier. (Deb= ian
> do this using run-parts for lots of things for those sorts of reasons)= .

The philosophy used in musl, which is somewhat different from the sor= t
of philosophy you might have when designing a new distribution, is not
to invent new policy but to avoid policy and build on existing,
already-widely-accepteed policy when it's unavoidable. There are LOTS of ways one could extend hostname lookups, ranging from NSS modules to
hosts.d and resolv.d, but rather than trying to support everything
imaginable (result: bloat and serious security considerations) in
libc, the musl approach to hostname lookup is that libc contains the
basics that are suitable for most/all simple systems, and anything
more advances can be provided by an external daemon running on
localhost that speaks DNS protocol and provides whatever lookup
semantics you desire.

Rich

--001a1134a71af7c39704eca76e2d--