Henrik Nordstrom wrote:
>What I do not quite get in this discussion is why one does not want to
>have the selected files available in the chroot in the first place?
Check out Jeff's talk on UML security and chroot:
>To chroot you need to be root. As root you are also allowed to map files
>around using mount --bind.
I can't really argue with that, except hundreds of /etc/mtab entries might
be annoying :) (yes, I know you could mount -n to hide them).
>Alle 16:08, martedì 14 ottobre 2003, Steve Schmidtke ha scritto:
> > yes. The discussion for a previous patch considered a "mm" table to hold
> > pool of /proc/mm files to handle one fd per process.
> > [....]
>Nooo! Don't make your like hard!
It's making the crackers lives hard that I'm attempting; making mine
difficult in the process is merely an occupational hazard.
>cd <chroot path>
>touch proc/mm #You must create the mount point. In this case it's a file.
>(as root)mount --bind /proc/mm proc/mm
><start Uml binary with "# chroot . linux ...." >
--bind is useful, and I'm trying to avoid it out of principle, not because I
don't know about it. In this case --bind would work because /proc/mm is
writable by everyone, so when the chroot wrapper drops root, the UML can
still access the file. That is not the case for all files you may want to
give a non-root UML access to.
>About the ugliness, it's only a userspace syntax matter. This is the v2 of
>umlwrap syntax. Instead of this:
> umlwrap -bind=21,/dev/shm/mconsole1 -dir=/home/uml -- \
> /bin/linux mem=48M uml_dir=/uml/ umid=um1 filemap=22,/uml/um1/pid \
> 22</dev/shm/pid filemap=21,/uml/um1/mconsole
>We can have this:
> umlwrap -dir=/home/uml -bind=/dev/shm/mconsole1,/uml/um1/mconsole \
> -map=r,/dev/shm/pid,/uml/um1/pid-- /bin/linux mem=48M uml_dir=/uml/
Yup, that's what I'm leaning towards.
>umlwrap will then setup the needed "filemap" options, at the end of the
The order of the command line arguments may be important: filemap options
should be parsed before options that reference them (i.e. they should come
first, not last, on the command line).
>However, does UML(unlike vanilla kernel) supports so long(>512
>char) command lines in the internal kernel part, (in the userspace part
>granted)? If not, we can use a patch out there that is already used by
Adam Heath is working on a patch for reading config files that will also
make command line length irrelevant. I like this approach since the UML
command line wouldn't have to be mangled to add filemap options to it.
Fretting that your Hotmail account may expire because you forgot to sign in
enough? Get Hotmail Extra Storage today!