bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: firmlink deleting files on boot / interpretation of find -xdev switc


From: Richard Braun
Subject: Re: firmlink deleting files on boot / interpretation of find -xdev switch
Date: Thu, 8 Sep 2016 16:04:37 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Sep 07, 2016 at 03:57:08PM -1000, Brent W. Baccala wrote:
> 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".

I think it's an acceptable workaround.

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

Probably.

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

Yes, but not only grep.

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

Unless that user has root access.

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

My current idea is something like Plan9 factotum, an agent that would
be used by any program, client or server, to validate that it's safe to
communicate through a given port.

-- 
Richard Braun



reply via email to

[Prev in Thread] Current Thread [Next in Thread]