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

Re: Hurd limitations

On Tue, Feb 27, 2001 at 09:41:38AM +1100, Brian May wrote:
>     Marcus> It should be possible to make fakeroot work if it doesn't
>     Marcus> already out of the box. I think the reason that prevented
>     Marcus> me from looking at it was that the build process required
>     Marcus> getopts from util-linux, and I hadn't made a crufty
>     Marcus> util-linux package back then. I would encourage you to try
>     Marcus> it.
> I can't get either sudo or fakeroot to work.
> sudo: won't accept my root password.

You will have to debug it. Maybe it is something simple like a missing suid
flag, maybe it is a bug.
> fakeroot: requires g++ which in turn requires libstdc++2.10-dev, which
> doesn't seem to be compiled yet.

I am sure you can work around this with some force-depends or other stuff
(configuring g++ and libstdc++2.10-dev in one run or so).
>     Marcus> It's quite easy: task devel packages suffer from similar
>     Marcus> linuxisms as other packages depencies.
> Solutions?

uh, contact the task package maintainer. Maybe we need architecture specific
task packages, or a suggests rather than a dependency, or architecture
specific task packages. Or (finally) we will have all-linux and all-hurd,
and make a different task package for all-linux or all-hurd. I don't know
what's the best solution is for task packages.

> Ok. Good.
>     Marcus> If you'd really want this feature in a filesystem, you'd
>     Marcus> add another RPC which would tell the filesystem server to
>     Marcus> set itself as the translator on a certain node. (Or just
>     Marcus> pass the port directly). But I don't think it is too
>     Marcus> useful a feature. What's the difference between mounting
>     Marcus> several times and just setting symlinks? [1] [2]
> symlinks, AFAIK, don't work in a chroot environment.

I suspect as much. But then, a mount also only works for root in Linux.
It might be quite easy to write some special symlink like translator which
could run as root in a chroot environment and get around the limitation, but
I have no clear vision on how to do that right now (you'd have to set it up
in a very specific way, because a chroot is actually about dropping references to
parent directories, and for this special translator, you need to keep a port
to the file system image or the parent directories). I am not sure this
mixes well with the chroot concept.

In any way, chroots are lame. In the Hurd, you can boot a complete sub hurd
as an arbitrary user, and with shadowfs you will have a convenient way to not
start from scratch but from the root filesystem.

>     Marcus> [1] In Linux, you don't get "sub mounts", in fact, there
>     Marcus> is nothing like a submount in linux. In the Hurd, you
>     Marcus> would always get the "submounts". To not get them, you'd
>     Marcus> need to take special precautions, and it would be quite
>     Marcus> impossible to do this cleanly, because even symlinks might
>     Marcus> just be implemented as translated nodes (see "showtrans
>     Marcus> /usr" for a faked example).
> I am not familiarly with sub mounts (at least the terminology), what
> do they allow you to do?

Well, I invented the terminology when writing the above paragraph. You
should forget it immeidately ;) In the Hurd, there is no central "phone book"
of all filesystem servers. Instead, every filesystem keeps a list of ports
to filesystem servers attached to a node in the specific filesystem it
provides. When you have a pathname resolution, the C library first queries
the root filesystem server with the full path. The prefix the root
filesystem can resolve is stripped, and a port to the next server returned
together with the remaining path component. The C library then retries the

So if you ask to open the file /mnt/mnt2/readme.txt, and mnt is a mounted
filesystem, and mnt2 another mounted filesystem, it goes like this:

C lib: "Hey, root fs, what's /mnt/mnt2/readme.txt?"
root fs: "dunno, but ask this port [mnt fs] for /mnt2/readme.txt"
C lib: "Hey, port [mnt fs], what's /mnt2/readme.txt?"
mnt fs: "dunno, you should ask this port [mnt2 fs] for readme.txt"
C lib: "Hey, port [mnt2 fs], what's /readme.txt?"
mnt2fs: "no such file or directory" or "this port is the file port you want".

So, before explicitely asking for a path name, the C library will not know which
filesystem server to query about. So we actually have a tree of "phone
books" (every filesystem server keeping a full list).


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

Reply to: