On Thu, May 12, 2011 at 08:58:08PM +0200, Tollef Fog Heen wrote: > ]] Roger Leigh > > | We currently use rbind for /dev, /sys and /proc. Could you possibly > | let me know what's mounted under each on the /host/, minus the > | autofs mounts? A complete list of the autofs mountpoints would also > | be useful. > > A slightly fuller list:
I've summarised this below.
/DEV
----
none /dev devtmpfs
none /dev/pts devpts
tmpfs /dev/shm or /run/shm tmpfs
mqueue /dev/mqueue mqueue [handled by autofs]
hugetlbfs /dev/hugepages hugetlbfs [handled by autofs]
/PROC
-----
none /proc proc
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc [handled by autofs]
/RUN and/or /VAR
-----------------
tmpfs /run or /var/run tmpfs
tmpfs /run/lock or /var/lock tmpfs
tmpfs /run/shm or /dev/shm tmpfs
none /sys sysfs
tmpfs /sys/fs/cgroup tmpfs
fusectl /sys/fs/fuse/connections fusectl
debugfs /sys/kernel/debug debugfs [handled by autofs]
securityfs /sys/kernel/security securityfs [handled by autofs]
cgroup /sys/fs/cgroup/systemd cgroup
cgroup /sys/fs/cgroup/cpuset cgroup
cgroup /sys/fs/cgroup/ns cgroup
cgroup /sys/fs/cgroup/cpu cgroup
cgroup /sys/fs/cgroup/cpuacct cgroup
cgroup /sys/fs/cgroup/devices cgroup
cgroup /sys/fs/cgroup/freezer cgroup
cgroup /sys/fs/cgroup/net_cls cgroup
cgroup /sys/fs/cgroup/blkio cgroup
Bindable=can bind mount from host
Remountable=can separately mount again inside chroot
Filesystem Bindable Remountable
-----------------------------------------------------
/dev Y N
/dev/pts Y Y
/dev/mqueue N N
autofs will cause breakage
/dev/hugepages N N
autofs will cause breakage
/dev/shm Y Y
/proc Y Y
/proc/sys/fs/binfmt_misc
Y Y
/run|/var/run Y Y
/run/lock|/var/lock
Y Y
/run/shm Y Y
/sys Y Y
/sys/fs/cgroup* unknown**
/sys/fs/fuse/connections
unknown, but likely works either way
/sys/kernel/debug
N N
autofs will cause breakage
/sys/kernel/security#
N N
autofs will cause breakage
** Does it make sense to have access to cgroup stuff inside a chroot?
So the questions that remain are:
For each of the above filesystems, which are /needed/ and which
are /optional/.
I assume from the existing breakage that /any/ autofs mountpoint
is unsuitable for bind mounting?
We currently generally bind mount all filesystems, but for kernel
filesystems like /proc, /sys, it it better just to mount directly
rather than binding?
For /dev we can probably get away with just /dev and /dev/pts.
- how essential are other filesystems such as mqueue and hugetlbfs?
Due to autofs, can't bind, but could mount separately.
- should we share memory by default by binding /dev/shm|/run/shm?
For /proc we can just mount /proc; binfmt_misc is a candidate (what
needs this?), but might be optional--potential for adding the
facility for optional mounts
For /run, we shouldn't share any of this by default; if the admin
wants to run services in a chroot, they can add it.
For /sys we can bind or mount it.
- how essential are the various submounts
- is cgroups strictly required?
- again for kernel/debug and kernel/security--it probably won't
be safe to bind these, but would we want to mount them separately
inside?
I guess most are optional. What I'd like to get is a list of
mounts which are:
- absolutely essential for any functionality (/proc)
- expected for normal use (/dev)
- needed for specific additional features (but otherwise optional
(fuse, debugfs).
Since schroot support various different "profiles" we can ensure
that each is added to the appropriate profile. More esoteric
stuff can be added but commented out by default.
Thanks,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
