Re: fakeroot status

[Marcus Brinkmann]

On Mon, May 13, 2002 at 05:45:21PM -0400, Roland McGrath wrote:
> There is no need to lock the node and indeed it is bad to do so, as you
> see.  (There is no need to lock because the file port never changes while
> the node lives.)

... and exec does it's own attempt at synchronization, so that it sees a
consistent file content.  Yeah, locking it was bogus.  I am wondering if for
the other calls locking is also unnecessary (although not harmful) as we are
only passing through and the locking of the "real" node at the end of the
chain will make sure nothing bad happens.

> I also fixed it not to use MACH_MSG_TYPE_MOVE_SEND, which
> is not safe in any interruptible Hurd RPC.

I don't understand this in the context of fakeroot.  We are only forwarding
a message, and never try again.  It seems to be the responsibility of the
caller to make sure he still has send rights to repeat the file_exec call.
What am I missing?

> Please investigate the latter problem.  Firstly, (assuming non-suid
> scripts)

Yes, non-suid scripts.  I wanted to spare me the disappointment of running a
program that would fail in both cases, with and without overriding file_exec :)

> it should find a name instead of using the /dev/fd kludge unless
> argv[0] has a stupid value.

argv[0] is fine.  I run bashbug.  It found bashbug in /usr/bin/bashbug.
But the io_identity is different for the FILE passed to file_exec, and
NAME_FILE looked up in the exec server.  I have not found out yet what the
reason is, I guess we are talking to different servers here when doing the
lookup.  But because we talk to the real filesystem when forwarding the message,
this would mean that we talk to the fakeroot server when exec looks up
/usr/bin/bashbug.  Does this make sense?

> But even with that broken, the /dev/fd/3 ought
> to work (unless the script itself closes the descriptor before using it or
> something).

Well, all scripts fail the same way, nothing is closing it.  I have not come
further with this one.  Not sure what I will try next.  Is there an easier
way to find out how PIDs in different Hurds map to each other than listing
all with ps -A and matching up the statistics?

> > There is another problem with fakeroot, and that is chmod.  It doesn't work
> > at all :)  I always get EOPNOTSUPP.  
> 
> I didn't pay close enough attention to what netfs does (or follow the nfs
> example closely), and that comment from netfs.h is not entirely clear on
> what the function has to do.  It gets called with no S_IFMT bits set when
> not changing.  I fixed fakeroot so it should work right.

Darn, forgot to test this!  Debugging the above hooked me up.  Will do this
next round.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de