Re: musl 1.0.x branch

[u-igbb@aetey.se]

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