musl 1.0.x branch

musl 1.0.x branch

[Rich Felker]

I'm about to prepare the 1.0.3 release, and I've been thinking a bit
about the future of the 1.0.x branch. Specifically I'd like to gauge
the extent to which it's being used. So far cherry-picking fixes to it
has been pretty easy, but it's an extra task to keep up with, and the
cherry-picking is probably going to turn into active backporting
somewhere in the near future as the rs-1.0 and master branches
continue to diverge.

If I don't hear back that there's significant use of the 1.0.x
releases by multiple projects, I'll probably plan to discontinue them
in the next 4 to 6 months, and in the mean time, to release only when
there are serious bugs (as opposed to releasing alongside every 1.1.x
release). Does this sound reasonable?

If anyone's using 1.0.x not for the sake of stability but because it
works better in some way for your setup (e.g. size, performance,
application compatibility, etc.) please let me know about that too so
we can see if there's a reasonable way to make 1.1.x work just as well
for you.

Rich

Re: musl 1.0.x branch

[u-igbb]

On Fri, Jun 06, 2014 at 01:56:17PM -0400, Rich Felker wrote:
> I'm about to prepare the 1.0.3 release, and I've been thinking a bit
> about the future of the 1.0.x branch. Specifically I'd like to gauge
> the extent to which it's being used. So far cherry-picking fixes to it

For us (the "Dapty" software repository at Aetey) there is no such thing
as a "system-wide-version of the c library", neither any corresponding
upgrade barrier whatsoever.

From this point of view, given the ABI stability a single supported
branch (in such a case "trunk") is fully sufficient.

Thanks for musl, it is a pleasure to build against it.

Rune

Re: musl 1.0.x branch

[Kevin Bortis]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

Hi

I also don't use the 1.0.x version because the 1.1.x branch at the moment
get a lot of new handy stuff. I would like something like the kernel
release model. Simply tag the 1.1.x branch as an RC and retag it, if no
regressions/bugs are found within a week or so. I think the most annoying
bugs, like not compiling on an architecture are easily found within that
timeframe.

Regards
 Kevin

Am Freitag, 6. Juni 2014 schrieb :

> On Fri, Jun 06, 2014 at 01:56:17PM -0400, Rich Felker wrote:
> > I'm about to prepare the 1.0.3 release, and I've been thinking a bit
> > about the future of the 1.0.x branch. Specifically I'd like to gauge
> > the extent to which it's being used. So far cherry-picking fixes to it
>
> For us (the "Dapty" software repository at Aetey) there is no such thing
> as a "system-wide-version of the c library", neither any corresponding
> upgrade barrier whatsoever.
>
> From this point of view, given the ABI stability a single supported
> branch (in such a case "trunk") is fully sufficient.
>
> Thanks for musl, it is a pleasure to build against it.
>
> Rune
>
>

[-- Attachment #2: Type: text/html, Size: 1417 bytes --]

Re: musl 1.0.x branch

[Anthony G. Basile]

On 06/06/14 13:56, Rich Felker wrote:
> I'm about to prepare the 1.0.3 release, and I've been thinking a bit
> about the future of the 1.0.x branch. Specifically I'd like to gauge
> the extent to which it's being used. So far cherry-picking fixes to it
> has been pretty easy, but it's an extra task to keep up with, and the
> cherry-picking is probably going to turn into active backporting
> somewhere in the near future as the rs-1.0 and master branches
> continue to diverge.
>
> If I don't hear back that there's significant use of the 1.0.x
> releases by multiple projects, I'll probably plan to discontinue them
> in the next 4 to 6 months, and in the mean time, to release only when
> there are serious bugs (as opposed to releasing alongside every 1.1.x
> release). Does this sound reasonable?

I moved the gentoo stages from 1.0.x to 1.1.1 on amd64, x86, armv7a and 
mipsel without any issues.  This includes about 200 core packages with 
both build and (some) runtime testing.  Everything was fine with both 
gentoo's vanilla and hardened toolchain with the exception of the 
__stack_chk_fail_local bug on hardened x86.

>
> If anyone's using 1.0.x not for the sake of stability but because it
> works better in some way for your setup (e.g. size, performance,
> application compatibility, etc.) please let me know about that too so
> we can see if there's a reasonable way to make 1.1.x work just as well
> for you.

I did not systematically check size or perf.  I found no issues with 
compatibility as I said above.  As far as I'm concerned, I can live 
without 1.0.x.

>
> Rich
>


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: musl 1.0.x branch

[Gustavo Zacarias]

On 06/06/2014 02:56 PM, Rich Felker wrote:

> If anyone's using 1.0.x not for the sake of stability but because it
> works better in some way for your setup (e.g. size, performance,
> application compatibility, etc.) please let me know about that too so
> we can see if there's a reasonable way to make 1.1.x work just as well
> for you.

For buildroot we've been in the 1.1.x branch when support was added in,
so we've got no particular interest in the 1.0.x branch.
Regards.

Re: musl 1.0.x branch

[Natanael Copa]

On Fri, 6 Jun 2014 13:56:17 -0400
Rich Felker <dalias@libc.org> wrote:

> I'm about to prepare the 1.0.3 release, and I've been thinking a bit
> about the future of the 1.0.x branch. Specifically I'd like to gauge
> the extent to which it's being used. So far cherry-picking fixes to it
> has been pretty easy, but it's an extra task to keep up with, and the
> cherry-picking is probably going to turn into active backporting
> somewhere in the near future as the rs-1.0 and master branches
> continue to diverge.
> 
> If I don't hear back that there's significant use of the 1.0.x
> releases by multiple projects, I'll probably plan to discontinue them
> in the next 4 to 6 months, and in the mean time, to release only when
> there are serious bugs (as opposed to releasing alongside every 1.1.x
> release). Does this sound reasonable?

Yes. I guess you could just drop 1.0.x support now and consider re-open
it if you get complains.
 
> If anyone's using 1.0.x not for the sake of stability but because it
> works better in some way for your setup (e.g. size, performance,
> application compatibility, etc.) please let me know about that too so
> we can see if there's a reasonable way to make 1.1.x work just as well
> for you.

Alpine Linux appreciate the idea of stable/maintenance branches, but we
figured that we'd be better off with the 1.1.x for out 3.0 stable
release. (which is kinda beta anyways). We need the new features.

So no interest in 1.0.x branch for Alpine Linux.

> 
> Rich

-nc

Re: musl 1.0.x branch

[Rich Felker]

On Mon, Jun 09, 2014 at 11:23:52AM +0200, Natanael Copa wrote:
> On Fri, 6 Jun 2014 13:56:17 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> > I'm about to prepare the 1.0.3 release, and I've been thinking a bit
> > about the future of the 1.0.x branch. Specifically I'd like to gauge
> > the extent to which it's being used. So far cherry-picking fixes to it
> > has been pretty easy, but it's an extra task to keep up with, and the
> > cherry-picking is probably going to turn into active backporting
> > somewhere in the near future as the rs-1.0 and master branches
> > continue to diverge.
> > 
> > If I don't hear back that there's significant use of the 1.0.x
> > releases by multiple projects, I'll probably plan to discontinue them
> > in the next 4 to 6 months, and in the mean time, to release only when
> > there are serious bugs (as opposed to releasing alongside every 1.1.x
> > release). Does this sound reasonable?
> 
> Yes. I guess you could just drop 1.0.x support now and consider re-open
> it if you get complains.

That's roughly what I proposed doing for now, except for throwing out
a release without anyone complaining/requesting it in cases where
there's a major bug (mainly just CVE-worthy ones, I think).

> > If anyone's using 1.0.x not for the sake of stability but because it
> > works better in some way for your setup (e.g. size, performance,
> > application compatibility, etc.) please let me know about that too so
> > we can see if there's a reasonable way to make 1.1.x work just as well
> > for you.
> 
> Alpine Linux appreciate the idea of stable/maintenance branches, but we
> figured that we'd be better off with the 1.1.x for out 3.0 stable
> release. (which is kinda beta anyways). We need the new features.

Yes. In hindsight 1.0 was probably slightly premature from a "ready
for distros" perspective, but releasing it as "1.0" was also probably
essential to discovering that. So at this point if the 1.0.x branch is
useful to anyone, I suspect it's users who have musl in embedded
products where they know it meets their needs already and don't want
to risk big changes, rather than distro-type users.

I'd actually be interested in looking at other approaches for next
time we reach a poing of needing a "new stable series" -- something to
avoid unbounded divergence between stable and master. 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.

Rich

Re: musl 1.0.x branch

[u-igbb]

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).

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.

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.

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.

(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)

Thanks,
Rune

Re: musl 1.0.x branch

[Rich Felker]

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

Re: musl 1.0.x branch

[Laurent Bercot]

On 10/06/2014 17:03, Rich Felker wrote:

> 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).

  And now there are even programs designed to help you do exactly that:
  http://skarnet.org/software/s6-networking/s6-sudo.html
  (Shameless plug of the day: achieved)

  However, despite being a good solution for noninteractive programs, the
unix socket mechanism isn't perfect. There are a lot of things it cannot
transmit without significant trouble - in particular terminals and
everything job-control-related, and signals, etc. I've done quite a bit
of thinking while writing s6-sudo, and my conclusion was that it's a
daunting task to get everything working properly with programs that
need a terminal; it would require ugly wrappers à la ptyget, and more.
I'm not convinced it's even worth trying, as opposed to tackling the
existing terminal-using privilege-granting programs and kicking the
suid out of them.

-- 
  Laurent

Re: musl 1.0.x branch

[Rich Felker]

On Tue, Jun 10, 2014 at 05:50:51PM +0100, Laurent Bercot wrote:
> On 10/06/2014 17:03, Rich Felker wrote:
> 
> >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).
> 
>  And now there are even programs designed to help you do exactly that:
>  http://skarnet.org/software/s6-networking/s6-sudo.html
>  (Shameless plug of the day: achieved)
> 
>  However, despite being a good solution for noninteractive programs, the
> unix socket mechanism isn't perfect. There are a lot of things it cannot
> transmit without significant trouble - in particular terminals and
> everything job-control-related, and signals, etc. I've done quite a bit
> of thinking while writing s6-sudo, and my conclusion was that it's a
> daunting task to get everything working properly with programs that
> need a terminal; it would require ugly wrappers à la ptyget, and more.
> I'm not convinced it's even worth trying, as opposed to tackling the
> existing terminal-using privilege-granting programs and kicking the
> suid out of them.

Sending the terminal fd over a socket with SCM_RIGHTS isn't
sufficient? If the privileged process has root, it should be able to
add itself to the process group of the client so that job control,
terminal signals, etc. work right.

Of course from a security standpoint it's better to put the UI that
uses the terminal in the client-side anyway, and limit the amount of
logic in the privileged server-side, but this is a good deal of extra
refactoring/redesign work if you have legacy applications.

Rich

Re: musl 1.0.x branch

[Laurent Bercot]

On 10/06/2014 18:37, Rich Felker wrote:
> Sending the terminal fd over a socket with SCM_RIGHTS isn't
> sufficient? If the privileged process has root, it should be able to
> add itself to the process group of the client so that job control,
> terminal signals, etc. work right.

  I may have missed something, but AFAICT, no, it cannot do that.

  From http://pubs.opengroup.org/onlinepubs/9699919799/functions/setpgid.html :

    setpgid() only allows the calling process to join a process group
    already in use inside its session or create a new process group
    whose process group ID was equal to its process ID.

  And I see nothing, not even setpgrp(), that could set the pgid to
an arbitrary value.

-- 
  Laurent

Re: musl 1.0.x branch

[Rich Felker]

On Tue, Jun 10, 2014 at 08:19:40PM +0100, Laurent Bercot wrote:
> On 10/06/2014 18:37, Rich Felker wrote:
> >Sending the terminal fd over a socket with SCM_RIGHTS isn't
> >sufficient? If the privileged process has root, it should be able to
> >add itself to the process group of the client so that job control,
> >terminal signals, etc. work right.
> 
>  I may have missed something, but AFAICT, no, it cannot do that.
> 
>  From http://pubs.opengroup.org/onlinepubs/9699919799/functions/setpgid.html :
> 
>    setpgid() only allows the calling process to join a process group
>    already in use inside its session or create a new process group
>    whose process group ID was equal to its process ID.
> 
>  And I see nothing, not even setpgrp(), that could set the pgid to
> an arbitrary value.

It's really odd that they include that text only in the RATIONALE,
which is non-normative. Perhaps it's duplicated somewhere else? Note
that the part of the quote you cropped was (at the beginning) "To
provide tighter security," which suggests there's no reason this
condition would need to be applied to root, but maybe it is anyway.

Rich

Re: musl 1.0.x branch

[Laurent Bercot]

On 10/06/2014 22:01, Rich Felker wrote:
> It's really odd that they include that text only in the RATIONALE,
> which is non-normative. Perhaps it's duplicated somewhere else? Note
> that the part of the quote you cropped was (at the beginning) "To
> provide tighter security," which suggests there's no reason this
> condition would need to be applied to root, but maybe it is anyway.

  Well, in the normative sections, there's this:

    ERRORS

    The setpgid() function shall fail if:

    (...)
    [EPERM]
    The value of the pgid argument is valid but does not match the
     process ID of the process indicated by the pid argument and there
     is no process with a process group ID that matches the value of
     the pgid argument in the same session as the calling process.

  which translates pretty clearly to "Thou shalt not join the process
group of another process lest it is of thy bloodline". No mention of
privileged processes here.

  And even if root could do that, it would basically force the daemon
to be started as root, and run some code run as root (if only to read
the pgid from the client), which would be ugly since not every suid
program is suid root.

-- 
  Laurent

Re: musl 1.0.x branch

[u-igbb]

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

Re: musl 1.0.x branch

[Rich Felker]

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

Re: musl 1.0.x branch

[u-igbb]

On Tue, Jun 10, 2014 at 05:51:56PM -0400, Rich Felker wrote:
> >  --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

Do you mean that getenv("SOMETHING") can be screwed if a different
thread is doing setenv("SOMETHINGELSE",...) at a wrong time?

(This "SOMETHING"'s value is _not_ to be modified under the lifetime of
the process.)

> when allowing a custom runtime path requires concatenating it with
> another string. Even if none of this were difficult, it's extra

An unmodified program can be impossible to compile against the
modified libc as we do it, as certain macros become no longer constants
but expressions to evaluate at run time. This is of course expected.

Luckily these applications needing both the functionality and specific
fixes are a minority.

> combinatorics for testing, and that issue was basically uclibc's
> demise.

Yes, I appreciate how much easier it is to build musl than uclibc,
without choosing among the myriads of options. Wonder which subset of
the combinations in uclibc actually was ever tested :)

> 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).

I readily trade off runtime efficiency for least possible complexity
and bloating. Thread safety is not to be traded though.

Filling the strings array at startup would be certainly acceptable here
both regarding the cpu and storage penalty. If the overhead for the
"standard" compile can be made negligible it would be certainly a very
nice way to allow us to "plug in" our indirections.

This would also remove any dependency between the details of the
implementation of get/setenv() and the correctness of applications
built here.

> *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.

Agreed, given some redesign we might have a much more convenient/sane
architecture. On the other side I am unsure the changes would not expose
new issues which might happen to be hard to solve, possibly "as hard as
safe setuid"?.. And then it would no longer be Posix-compatible
and would probably need a corresponding standardization effort (sigh).

> > 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.

Yes I looked at it - it is unfortunately also a solution for goals
"other than ours". AFAICS it still assumes a hardcoded database
placement (/etc/tcb). In this sence it is orthogonal to what we do, we
may choose to use it for its nice virtues but we still need to be able
to point out the necessary tcb shadow database instance per process,
not per compiled binary.

Thanks for the positive discussion Rich.

Regards,
Rune

Re: musl 1.0.x branch

[Rich Felker]

On Wed, Jun 11, 2014 at 12:24:19PM +0200, u-igbb@aetey.se wrote:
> > 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
> 
> Do you mean that getenv("SOMETHING") can be screwed if a different
> thread is doing setenv("SOMETHINGELSE",...) at a wrong time?

Indeed. In POSIX, being non-thread-safe (which setenv is) is a very
strong condition: it allows behaviors such as the above. Also note
that you can modify the environment via extern char **environ, and in
fact doing so with (compiler-specific or C11) atomics is the only safe
way to modify the environment in a multithreaded program.

> (This "SOMETHING"'s value is _not_ to be modified under the lifetime of
> the process.)

Indeed, but the environment could otherwise be modified.

XSH 2.9.1 Thread-Safety reads:

"Since multi-threaded applications are not allowed to use the environ
variable to access or modify any environment variable while any other
thread is concurrently modifying any environment variable, any
function dependent on any environment variable is not thread-safe if
another thread is modifying the environment; see XSH exec."

This makes "dependent on an environment variable" a formal property of
standard interfaces which introduces subtle breakage if/when a
function which is not specified to be dependent on an environment
variable actually uses one. The only safe solution I know to this
problem is to do the environment processing at program start time.

> > when allowing a custom runtime path requires concatenating it with
> > another string. Even if none of this were difficult, it's extra
> 
> An unmodified program can be impossible to compile against the
> modified libc as we do it, as certain macros become no longer constants
> but expressions to evaluate at run time. This is of course expected.

Hopefully this only affects programs using paths.h or similar, which
are legacy mess I just left around because it sometimes helps build
programs which are otherwise a pain to build.

> > > 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.
> 
> Yes I looked at it - it is unfortunately also a solution for goals
> "other than ours". AFAICS it still assumes a hardcoded database
> placement (/etc/tcb).

Yes. I suppose it wouldn't fundamentally have to do so, since programs
authenticating user accounts would be configured to the right location
for the system user database, but it seems safest (and of course
simplest) to always use that location anyway.

> In this sence it is orthogonal to what we do, we
> may choose to use it for its nice virtues but we still need to be able
> to point out the necessary tcb shadow database instance per process,
> not per compiled binary.

Yes. BTW your approach is also very nice from a unit-testing
perspective. It's hard to test things like dns resolver, user
database, etc. due to the difficulty of mocking in controlled
configurations for them. Modern Linux does however provide user
namespaces / mount namespaces which allow doing this, and that's
probably what we'll use for testing at least in the short-term (it
also makes it easy to apply the tests to other libcs).

Rich

Re: musl 1.0.x branch

[u-igbb]

On Wed, Jun 11, 2014 at 09:09:37AM -0400, Rich Felker wrote:
> any
> function dependent on any environment variable is not thread-safe if
> another thread is modifying the environment; see XSH exec."

> This makes "dependent on an environment variable" a formal property of
> standard interfaces which introduces subtle breakage if/when a
> function which is not specified to be dependent on an environment
> variable actually uses one.

Oh indeed. Seen from this angle the problem is apparent.

> The only safe solution I know to this
> problem is to do the environment processing at program start time.

I am not really afraid of such thread-related breakage (even if the
application uses threads, the chance of corruption is quite low).
Nevertheless I'll aim to fix the patches and move the value fetches
to the startup, as you mention.

> Hopefully this only affects programs using paths.h or similar, which
> are legacy mess I just left around because it sometimes helps build
> programs which are otherwise a pain to build.

The programs including paths.h are in a sense "well behaving",
the other ones which boldly use hardcoded strings are more
unfriendly to modifications. In my eyes path.h should exist, be used
and actually define the databases-related-macros, which would serve
as the redirection means - it is what we do.

A path.h with mere constants is indeed a nuisance.

> > Yes I looked at it - it is unfortunately also a solution for goals
> > "other than ours". AFAICS it still assumes a hardcoded database
> > placement (/etc/tcb).
> 
> Yes. I suppose it wouldn't fundamentally have to do so, since programs
> authenticating user accounts would be configured to the right location
> for the system user database, but it seems safest (and of course
> simplest) to always use that location anyway.

No matter which location this would be, it is one constant for all concerned
processes, assuming a single database instance in a local place to be used
by all processes on the host - the Unix practice hardly ever questioned
by anyone :( aka "blindly followed for ages" :)

> Yes. BTW your approach is also very nice from a unit-testing
> perspective. It's hard to test things like dns resolver, user
> database, etc. due to the difficulty of mocking in controlled
> configurations for them. Modern Linux does however provide user

I would be happy to rework and submit the patches, indeed they are a
straightforward and fine-grained instance isolation tool, without the
constraints of chroot and similar. Just never setuid the binaries
using the resulting library :)

> namespaces / mount namespaces which allow doing this, and that's
> probably what we'll use for testing at least in the short-term (it
> also makes it easy to apply the tests to other libcs).

It is nice to have a choice.

Regards,
Rune

Re: musl 1.0.x branch

[Natanael Copa]

On Tue, 10 Jun 2014 12:03:56 -0400
Rich Felker <dalias@libc.org> wrote:

> 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).

You probably knew but this is what OpenBSD does instead of suid + PAM:
http://en.wikipedia.org/wiki/BSD_Authentication

I have always liked this approach.

-nc

Re: musl 1.0.x branch -- OT

[u-igbb]

On Tue, Jun 10, 2014 at 11:25:06PM +0200, Natanael Copa wrote:
> You probably knew but this is what OpenBSD does instead of suid + PAM:
> http://en.wikipedia.org/wiki/BSD_Authentication
> 
> I have always liked this approach.

+1

SUN invented several things which became hugely popular.
Unfortunately quite a few of them were extremely flawed by design.

Nsswitch, NFS and PAM are notable examples of the latter.

Nice that we can at least skip nsswitch with musl.

Rune

Re: musl 1.0.x branch

[Rich Felker]

On Tue, Jun 10, 2014 at 11:25:06PM +0200, Natanael Copa wrote:
> On Tue, 10 Jun 2014 12:03:56 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> > 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).
> 
> You probably knew but this is what OpenBSD does instead of suid + PAM:
> http://en.wikipedia.org/wiki/BSD_Authentication
> 
> I have always liked this approach.

I'm not really familiar with BSD stuff, but yes, it sounds like a much
better alternative to the insanity (which is the only way you can
describe loading arbitrary, poorly-written code directly into
privileged processes for authentication/login purposes) of PAM.

Of course an independent PAM implementation could do the same thing by
offloading the actual work to a separate authentication daemon (and
dropping support for all of the other junk PAM can do to the calling
process) while keeping the same API or even ABI.

Rich

Re: musl 1.0.x branch

[Oliver Schneider]

Hi Rich,

in my case I'll try to stick to the latest version labeled "stable".

The website currently still doesn't call 1.1.2 stable, so I simply
haven't upgraded to it yet.

* Latest release is 1.1.2.
* Current stable maintenance release is 1.0.3.

I think many others will share thus view, because it's best to rely on
the developer for that information, i.e. whether some code is deemed
stable or not.

Best regards,

// Oliver

On 2014-06-06 17:56, Rich Felker wrote:
> I'm about to prepare the 1.0.3 release, and I've been thinking a bit
> about the future of the 1.0.x branch. Specifically I'd like to gauge
> the extent to which it's being used. So far cherry-picking fixes to it
> has been pretty easy, but it's an extra task to keep up with, and the
> cherry-picking is probably going to turn into active backporting
> somewhere in the near future as the rs-1.0 and master branches
> continue to diverge.
> 
> If I don't hear back that there's significant use of the 1.0.x
> releases by multiple projects, I'll probably plan to discontinue them
> in the next 4 to 6 months, and in the mean time, to release only when
> there are serious bugs (as opposed to releasing alongside every 1.1.x
> release). Does this sound reasonable?
> 
> If anyone's using 1.0.x not for the sake of stability but because it
> works better in some way for your setup (e.g. size, performance,
> application compatibility, etc.) please let me know about that too so
> we can see if there's a reasonable way to make 1.1.x work just as well
> for you.
> 
> Rich
> 

Re: musl 1.0.x branch

[Rich Felker]

On Wed, Jun 11, 2014 at 10:41:06AM +0000, Oliver Schneider wrote:
> Hi Rich,
> 
> in my case I'll try to stick to the latest version labeled "stable".

Thanks for the feedback -- it's nice to know at least somebody is
using it and the effort packaging isn't going to waste.

> The website currently still doesn't call 1.1.2 stable, so I simply
> haven't upgraded to it yet.
> 
> * Latest release is 1.1.2.
> * Current stable maintenance release is 1.0.3.
> 
> I think many others will share thus view, because it's best to rely on
> the developer for that information, i.e. whether some code is deemed
> stable or not.

For reference (I'm not sure this is published anywhere; it probably
should be) "stable" here means "no unnecessary changes that risk
disturbing an existing working deployment". It's not a matter of how
reliable or bug-free the release is.

My intended audience for stable is users who have fairly constant sets
of packages built against musl and who don't want to deal with changes
that might affect their build procedures, nonstandard or undocumented
behaviors their programs might be relying on, etc. The release series
from master (currently 1.1.x) on the other hand is probably a better
choice if you're expanding your set of software built against musl,
aiming to support a widening range of kernel versions, etc.

Rich

Re: musl 1.0.x branch

[Oliver Schneider]

Hi Rich,

On 2014-06-11 13:16, Rich Felker wrote:
> For reference (I'm not sure this is published anywhere; it probably
> should be) "stable" here means "no unnecessary changes that risk
> disturbing an existing working deployment". It's not a matter of how
> reliable or bug-free the release is.
Well that's clear. Since we cannot reliably know how many defects exist
in a software project.

> My intended audience for stable is users who have fairly constant sets
> of packages built against musl and who don't want to deal with changes
> that might affect their build procedures, nonstandard or undocumented
> behaviors their programs might be relying on, etc. The release series
> from master (currently 1.1.x) on the other hand is probably a better
> choice if you're expanding your set of software built against musl,
> aiming to support a widening range of kernel versions, etc.
Indeed. Then I should probably switch to the newer release series.

Perhaps this is worth pointing out? Is there a Wiki in which one can get
edit rights so as to write these things down for future users?

With best regards,

// Oliver

Re: musl 1.0.x branch

[Rich Felker]

On Thu, Jun 12, 2014 at 06:46:10PM +0000, Oliver Schneider wrote:
> Hi Rich,
> 
> On 2014-06-11 13:16, Rich Felker wrote:
> > For reference (I'm not sure this is published anywhere; it probably
> > should be) "stable" here means "no unnecessary changes that risk
> > disturbing an existing working deployment". It's not a matter of how
> > reliable or bug-free the release is.
> Well that's clear. Since we cannot reliably know how many defects exist
> in a software project.

I don't think it's automatically clear. For many projects with
"stable" series, the "development" series is documented as having
major feature regressions or temporary breakage due to design changes,
partial or full rewrites of components, etc. and is intended only for
people who want to follow the new development and who can live without
whatever features are broken in the mean time (or even, in some cases,
permanently dropped).

With musl, on the other hand, the intent is that releases from master,
and even git master itself, are intended to be at least as good as the
previous release in terms of functionality and bugs. Sometimes this
intent isn't fully met, but it's the intent, and I think it differs
significantly from the stability model of many other projects.

> > My intended audience for stable is users who have fairly constant sets
> > of packages built against musl and who don't want to deal with changes
> > that might affect their build procedures, nonstandard or undocumented
> > behaviors their programs might be relying on, etc. The release series
> > from master (currently 1.1.x) on the other hand is probably a better
> > choice if you're expanding your set of software built against musl,
> > aiming to support a widening range of kernel versions, etc.
> Indeed. Then I should probably switch to the newer release series.
> 
> Perhaps this is worth pointing out? Is there a Wiki in which one can get
> edit rights so as to write these things down for future users?

We really need to get account creation sorted out on the wiki; right
now it's restricted due to spam. Contact Jeremy Huntwork
<jhuntwork@lightcubesolutions.com> if you need access.

Rich