Re: fakeroot inquiry
> What will it take to port fakeroot to the Hurd?
I had never bothered to understand what fakeroot really did before now.
Having looked at it tonight, I wish I had done something about it earlier.
There are several answers, each one superceding the last. I'll give you
them all in order, not because you really want them all, but just because
I'm like that.
The unimplemented functions are the sysvipc interfaces (msgsnd/msgrcv et
al). They're not implemented. They would not be real hard to implement
and I won't get into to how to implement them, but there is almost never
any worthwhile reason to be using them and so will probably never implement
them. So one thing you could do is implement some of all that. But...
It's just goofy that fakeroot's communication with its little daemon is
implemented using those interfaces instead of something else less hairy.
The whole LD_PRELOAD plan of attack that fakeroot uses can work on the Hurd
just as well as it does on Linux. So another thing you could so is rewrite
fakeroot/faked to use a different form of communication (like named pipes
or local-domain sockets). But...
This is something where the Hurd can easily do better than the original.
fakeroot uses some sleazy hacks at the level of the libc POSIX interfaces
because it wants to interpose on filesystem actions. It is natural and
easy in the Hurd just to interpose on filesystems at the RPC level. That's
what translator do. You don't have to worry about every program getting
fakeroot's magic library hacks into its environment properly, just anything
pointed at this translated filesystem gets the translator's behavior.
So, following the described behavior of fakeroot, I whipped up a translator
to do approximately the same thing. I've checked the new file
trans/fakeroot.c into hurd cvs with code that I have compiled but not
tested at all. (It's just a standalone file that you should be able to
compile by itself on a Hurd system if that is more convenient than building
it from the hurd source tree.) The idea with this translator is that you do:
$ mkdir foobar
$ settrans foobar /hurd/fakeroot
$ install -c -o root -m 4755 /foo/bar/blah foobar/blah
$ ls -l foobar
and are told a lie about what owner and mode foobar/blah really has in the
underlying directory. Note that fakeroot always accesses the underlying
directory tree as itself (i.e. you, the owner of the underlying node)
regardless of who the client is making the request. So it is a whopping
security hole if you let it be. It might make sense to have it just refuse
access to the virtual directory for anyone other than the owner of the
underlying node. For now if you are concerned with that just put the
underlying directory inside a directory that's not accessible to anyone
else before setting the translator on it.
But... I did all that taking the point of view of accomplishing on the
Hurd specifically what fakeroot does on Linux: fake out the apparent IDs
and permissions on files residing in the normal filesystem. But the
higher-level goal is temporarily installing files with arbitrary IDs and
mode bits in a freshly-created staging area just long enough to pack them
up into an archive. The Hurd can do that better and entirely cleanly.
> Well, IMHO a good solution is to hack ext2fs to allow that.
If what you want is to create an actual small filesystem and allow a
non-root user to act is if they were root within it, then that is doable.
I have long thought a useful general feature would be a uid and gid
remapping facility. That is, some common code in libfshelp to consult
mapping tables (it could use ihash) with an argp parser to set them up.
The filesystem libraries could easily use this, so that all filesystem
translators have common command-line option syntax for this. A handy
additional option would be a shorthand for "map the translator's euid to root".
The "fakeroot" purpose of building packages just wants to fake attributes
long enough to have tar read them back that way. This feature is useful
for things other than that, such as making filesystem images to put onto
floppy or use for direct disk copy (i.e. used on ext2fs when you plan to
keep the resulting ext2fs image), or unrelated purposes like mapping users'
local IDs to an NFS server's uncorrelated ID space.
For building packages, you could just use a tmpfs with uid-mapping.
i.e.
$ settrans -ca my-pkg /hurd/tmpfs --map-uid=`whoami`:root
$ make install prefix=my-pkg
$ tar cf my-pkg.tar my-pkg
$ settrans -g my-pkg
$ rm -f my-pkg
Note also, this all is only the filesystem part of what fakeroot does.
fakeroot also fakes out getuid and so forth so that e.g. `whoami' says
`root'. Again, the Hurd can do it better. The obvious thing is to
interpose on the auth port, so it authenticates to servers as the normal
user, but reports to the user himself that he is root to reinforce his
delusions of grandeur. I haven't written that program yet, but it's easy.
--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: