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
lookup.
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).
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
Reply to: