[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACCP0GpzwjeT0JdXFTdgB=B-4Lqq0gMzr0W=-JecRnxqq2bYOQ@mail.gmail.com>
Date: Tue, 3 Dec 2013 20:49:32 +0000
From: Raphael Cohn <raphael.cohn@...rmmq.com>
To: musl@...ts.openwall.com
Subject: Re: _PATH_LASTLOG
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@...rmmq.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 <dalias@...ifal.cx> 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
>
Content of type "text/html" skipped
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.
