On Wed, Sep 7, 2016 at 11:49 AM, Richard Braun <rbr...@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
