Re: Passive versus active translators

[Igor Khavkine]

On Thu, Jun 21, 2001 at 11:48:02PM -0500, Neal H Walfield wrote:
> My point is that whether a translator is started by the filesystem or by
> settrans, the behavior should be basically the same.
> 
> > >   o Current working directory
> > >           - settrans: user's current working directory
> > >           - libfshelp: the directory in which we find the
> > >             translator.
> > In the case of settrans it is logical to set the cwd of the translator
> > to the user's current cwd like for any other program the user runs. And
> > as for the second case, there's not much chioce but to start the
> > translator in the directory of the node. And it also makes sense,
> > think relative symlinks.
> 
> I do not see how this makes sense.  I see how it is logical, however, it
> is misleading.  Consider the following:
> 
>       # settrans -cap ~/foo /hurd/isofs cdimage
> 
> The active translator will start, however, once it is stopped, the
> filesystem will to be able to restart it.  In this scenario, guessing
> from the `-ap', the user likely wants to make sure that the translator
> is setup and correctly and then wants to forget about it.

You're confusing the behavior of settrans with mount. If you do:

        # cd /dev; mount -t iso9660 hdd ~/foo

Then even though hdd was indicated as with a relative path, the full
location of the device file is communicated by mount to the kernel.
and thus will work. That's because mount knows that hdd is a special
argument that is a file and has to be resolved to a full pathname.
But you run into problems with fstab and automount because to get it
to work you still have to specify the full path name of the devices.
Settrans is inherently different from mount, it knows only about
two special arguments the node and the translator. The node's full
path is resolved when the translator is started. But settrans knows
nothing about the arguments to the translator. It doesn't even have
to be a filename. In case of, lets say, a random number generator
translator its argument could be the random seed.

So it has to be the translator's responsibility to resolve all
of its arguments properly. Since settrans can't do anything
about the arguments to the translator, it's important to realize
that they will work like arguments to the translator if it was
started by the user like a regular program.

> > >   o User ids
> > >           - settrans: The euid and egid of the user that lauched
> > >             settrans.
> > >           - libfshelp: The uid and gid of the node.
> > The user might not always (unlike root) have the ability change
> > the euid and egid of a process to those of an arbitrary node.
> > So the translator has to be started with the priviliges of the
> > user.
> 
> Not true; make settrans suid root.

This would open up a whole flood of security risks.

> > And if a passive translator is started up with the
> > priveleges of the user that wakes it up it, it would be impossible
> > to implement some things that translators do already. For example
> > a filesystem translator has to run with the priveleges of the
> > underlying node, otherwise it would be unable to write any data
> > to store-nodes which have root-only write permissions.
> 
> I am not suggesting this at all.  This is what I am trying to
> communicate:
> 
>       # cd
>       # sudo settrans -acp foo /hurd/ext2fs /dev/hd0s2
> 
> ext2fs is launched as root.root.  However, the passive translator will
> run as root.neal (as my home directory is neal.neal).  Now, because the
> Hurd has group leaders, I will be considered an owner of the translator.
> 
> The active translator should be started with the same ids that the
> passive translator will be started with.

I think you're getting off the wrong foot when you start assuming that any
user can `sudo settrans' anytime. If someone who has root priveleges
puts a translator on a node with permissions root.neal they should know
what they are doing just like with suid executables. But I do agree
that settrans should have options to set the uid and gid of a translator
if you have the authority, but by no means should the default ones be
the same as the underlying node.

Igor