On Wed, Sep 7, 2016 at 11:49 AM, Richard Braun
<rbraun@sceen.net> wrote:
We really, really don't want to make standard Unix tools aware of
Hurd-specific stuff, because that allows us to completely reuse the
work of others. With a trend towards systemd, it's even more likely
that our efforts will be put into providing some of the stuff specific
to _others_ system instead.
Personally, I would consider any solution that isn't entirely contained
in the Hurd (kernel, servers, glibc and related) to be a no-go.
OK,
I understand. I personally lean in the direction of adding something
like an "-xtrans" switch to find, telling it not to enter translators,
because that's a lot clearer than usurping the interpretation of
existing switches from systems without translators. However, I also
appreciate the wisdom in what you say, in which case I revert to my
earlier suggestion of modifying the FTS code in glibc to interpret
FTS_XDEV to mean "don't enter translators".
> Makes sense. The parent is where you've got all that information. Is
> there no way to retrieve it?
There might, I haven't looked thoroughly, and it could be implemented
if needed.
OK. I just though I might be overlooking something obvious.
We'd also have to make sure that remove()/unlink()/rmdir() don't cross
the file system into the untrusted translator.
How
do we do that without modifying programs? Probably the FTS code;
that's what both rm and find seem to use to transverse directory
structures.
Also, I agree with Kalle that not entering
translators should be the default for "rm". If so, and we modify FTS
without touching the programs, then it also becomes the default for
"chmod", "chown", "chcon", "grep", and "du". In particular, I don't
think we want that for "grep" (not so sure about the others).
If
I understand you, Richard, you'd like to see grep's default be to enter
trusted translators, but not untrusted ones. Am I correct?
I'm not sure I understand when you say "More limited in that our trust
set is finite". Actually, we'd like our trust set _not_ to be finite,
since we want the system to be extensible, by both the admin and any
unprivileged user. Again, too rigid.
I meant that we have a standard set of trusted translators in /hurd, and that set is finite, just like the set of programs in /bin is finite. We certainly don't have a means for verifying any old program in a user's bin directory to see if it's safe to run as root.
Would you like to see a scheme where only a limited set of trusted translators were accessible to a process, and the user had the ability to extend the trust set of his own processes? Something like adding directories to your own PATH, but this would apply to translators running under different UIDs, and not just programs that you started yourself?
agape
brent