XPost: comp.unix.misc
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
Ivan Shmakov <ivan@siamics.net> writes:
[Frankly, I'm somewhat at loss as to where this discussion
should continue. The news:comp.os.linux.misc appears to be
a popular choice, yet the subject at hand isn't Linux-specific.
Then, news:comp.unix.misc looks reasonable, except it doesn't
seem to have seen any on-topic traffic in months. Still, I'm
going to cross-post and set Followup-To: there; feel free to
cross-post to a more appropriate group and set Followup-To:
accordingly instead.]
Out of curiosity, do you use multiple accounts solely to get
multiple $HOME directories, or do you actually find some use for
separate UIDs?
Yes, just to organise things with different directories.
Well-behaving programs are ought to use whatever directory
specified in $HOME, so it should be possible to use several home
directories without ever switching uids. Such as, e. g.:
$ export HOME=/home/jrh
$ export HOME=/home/jrh/project-codename
or even (provided such a directory has been created by root):
$ export HOME=/home/codename-jrh
(I used to set HOME to a newly created disposable directory to
test whether whatever bug I observe is caused by my ~/
configuration, or also happens with no user customizations
whatsoever. For well-behaving software, this achieves effect
similar to that of $ emacs -q.)
Unfortunately, some software refers to passwd(5) data directly
instead, leaving no way for the user to override the home
directory location. In particular, this was the behavior (IIRC)
of programs based on older Glib versions. And I vaguely recall
that Emacs might have been affected as well. Thankfully, it's
easy to check out; e. g.:
$ HOME=/tmp emacs --batch \
--eval='(print (expand-file-name user-emacs-directory))'
Loading 00debian-vars...
...
"/tmp/.emacs.d/"
$
Personally, I use chroots somewhat extensively (typically, most of
the "payload" software on my systems is installed in chroot
environments, accessible via schroot(1); this tends to simplify
system upgrades in a way), and I do use different "home" filesystems
for different chroots. Hence, I effectively use a single account
(and UID), but several $HOME directories.
Sounds interesting but I did not understand anything but the actual
words. It looks like I should read up on this
The idea is simple. An installed system is just a bunch of
programs. Now, we can copy these programs into an arbitrary
directory, and the only issue with running them from there would
be that /otherwhere/bin/foo is built to refer to filenames like
/lib/libfoo.so and /etc/foorc -- which are in fact available as
/otherwhere/lib/libfoo.so and /otherwhere/etc/foorc, respectively.
The chroot(2) syscall replaces the notion of "/" for the process
with an arbitrary directory. Hence, if instead of the usual
fork and exec routine we do fork, chroot ("/otherwhere") and
then exec, the assumptions bin/foo is built under will hold,
and it will be able to refer to the files under their compiled-in
names, such as /etc/foorc (which will then be understood as
/otherwhere/etc/foorc so long as the "base" system is
considered) and /lib/libfoo.so.
Now, there're only two issues to resolve. From the user's
perspective, chroot(2) is privileged. Thus, we need a setuid-root
program that would check if the user is allowed to use a chroot
and perform the syscall for him if so. Debian offers schroot(1)
for this purpose ($ schroot -c mychroot -- [COMMAND]...;
if no COMMAND given, an interactive shell is started.)
Another issue is to get a system installed under a directory.
In Debian, the respective program is debootstrap(8); like:
# debootstrap stable /srv/chroot/mychroot
http://http.debian.net/debian/
(This is the same command used by Debian Installer to install
an "ordinary," non-chroot system to the target media.)
This would likely be followed shortly by APT invocations, like:
# chroot /srv/chroot/mychroot apt-get update
...
# chroot /srv/chroot/mychroot apt-get install -- apg file rsync time zip ...
Chroot environments provide a degree of isolation, as processes
with a root directory set to /otherwhere cannot access filenames
outside of said directory. (Although it's still possible for a
chrooted process to inherit or receive a file descriptor from a
non-chrooted process.) Of course, processes running as root are
still fully privileged, and can, for instance, create device
files and thence wreak any kind of havoc on the system as a whole.
Additional syscalls are available to further isolate processes,
which can be used alongside chroot(2). These are the basis for,
e. g., FreeBSD "jails" and Linux "containers" (LXC.)
Chroot environments provide an easy way to run software
belonging to an older or newer version of the system. Moreover,
as upgrades to chroots are (to a degree) independent to the
upgrades of the base system, the breakage of software in any
chroot (which occasionally happens during upgrades) in no way
affects the operation of the base system, or other chroots,
which is how using chroots simplifies system maintenance for me.
--
FSF associate member #7257 np. Piano Sonata No. 8 in C minor,
http://am-1.org/~ivan/ Op. 13 "Pathetique" -- Adagio cantabile
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)