[Buildd-tools-devel] schroot question (fwd)

[Steven Hirsch]

Sorry if this is a dup, but I never saw the first reply appear on the 
list!


-- 

---------- Forwarded message ----------
Date: Sun, 11 Jan 2009 13:03:50 -0500 (EST)
From: Steven Hirsch <snhirsch at gmail.com>
To: Roger Leigh <rleigh at codelibre.net>
Cc: buildd-tools-devel at lists.debian.org
Subject: Re: [Buildd-tools-devel] schroot question

On Sun, 11 Jan 2009, Roger Leigh wrote:

>> The automount daemon needs to be started in the actual execution context
>> of that child process.  The '/net' that it tries to cover must be
>> relative to the chroot-ed environment and cannot be done from outside
>> (e.g. by specifying $SCHROOT_MOUNT_LOCATION/net).
> 
> OK.  You could do "chroot $SCHROOT_MOUNT_LOCATION mount -t autofs /net"
> or similar inside the chroot in order to mount that way.

Unfortunately, that simply does not work.  It appears to succeed, but I find 
that the daemon isn't there when the command completes.

>> This suggests that autofs could never be tied to a unique session "from
>> the outside" and probably only makes sense for a persistent session where
>> one obtains a command prompt.  Otherwise, each and every schroot command
>> would need to start/stop its own daemon.  Does this make sense?
> 
> I think so.  So if I understand correctly, only child processes can make
> use of the mount?

No, that's not a requirement.

> However, this doesn't appear to be the case on the
> host, where you can just run restart autofs at any time.

Yes, but in that basic case both autofs AND processes that wish to use the 
mounts are peers in the same filesystem namespace and children of a common 
process (init, if you want to go back that far).

I seems that only _peer_ processes to the automount daemon that all initiate in 
the same process context can make use of the mount.  When attempting to set 
this up from the setup.d scripts, the eventual context is not a peer in that 
sense.

To be clear about my terminology:  In the sense that I was using it, a chroot() 
'session' is anything that occurs directly in (or in a child of) a process 
that's executed the kernel chroot() call (consider the root environment to be 
the base case of this).  In schroot parlance, you deem a session to be simply 
anything that shares the same filesystem namespace. It's sort of confusing, 
because in a sense they are both "sessions". Perhaps the view I'm taking should 
be called simply "execution context" :-).


>> If so, it would be great to have a mechanism for use in such "login"
>> sessions for running scripts after the fork + chroot() takes place and
>> prior to root privileges being dropped.
> 
> You could possibly abuse the "command-prefix" configuration option to
> do this with a custom script inside the chroot.  However, there are
> likely better alternatives.
> 
> I already want to take this approach in order to support things such
> as per-process namespaces.  However, these are inherited by child
> processes and so can't be used at present.  I was thinking of having
> schroot run as a daemon (either just one or one per chroot) which
> creates a PTY for each chroot, and when you run a command it connects
> you to the PTY like a screen session would; the user would get
> stdin/stdout/stderr on their terminal or redirected as expected.  This
> would allow stuff to run persistently inside such as daemons and
> autofs.
> 
> This approach is probably also desirable to support KVM/qemu and other
> virtualisation mechanisms as well in addition to basic chroot
> virtualisation.

I believe that would solve the entire issue.  The chroot environment is then 
more like a virtual machine in its own right.

--