Re: [RFC][PATCH] Add envvar IO_BUFMODE to forcibly set buffering mode

[Zack Weinberg <zackw at panix dot com>]

On Wed, Mar 22, 2017 at 2:09 PM, Sunyeop Lee <sunyeop97@gmail.com> wrote:
> I understand
> it breaks standard semantics, but does it need to be disabled for
> setuid programs even if it's secure?

The problem is that we can't _prove_ it's secure.  There _could be_ a
setuid program somewhere in the world whose security rests on
assumptions that this environment variable would break.  We have no
way of knowing.

> Anyone already can force "line
> buffering mode" using pty even on setuid programs.

Yes, but they cannot simultaneously set line-buffering mode and make
isatty(fileno(stdout)) be false.  The environment variable introduces
a new possibility.

> I'm asking if it's
> possible to allow only forced "line buffering mode" for setuid
> programs instead of disabling it.

I don't think it's safe.

Besides that, a few more concerns for you:

1) This feature should only affect stdout and stderr.  The way you did
it, I think it affects _every_ FILE object, which is not ok.
2) The environment variable should have a name that starts with GLIBC_.
3) It is not safe to call getenv() in multithreaded programs (see
generally https://sourceware.org/bugzilla/show_bug.cgi?id=15607) --
all internal uses of getenv() in libc need to be moved to very early
in startup, before threads can exist (which I think means inside
ld.so).  That's not your problem, but _new_ calls to getenv() should
only happen that early.

You can address 2, 3, and the setuid issue simultaneously by using the
tunables framework (er, is the tunables framework documented anywhere?
I'm not finding a gentle introduction :-P )

zw