Tag Info

Hot answers tagged

30

The Arch Linux Wiki suggests the following commands: cd /mnt/arch # or where you are preparing the chroot dir mount -t proc proc proc/ mount -t sysfs sys sys/ mount -o bind /dev dev/ I can confirm they worked for me.


24

Here are some resources: ArchLinux wiki on "Change Root" ArchLinux Wiki on "Reinstalling GRUB" Gentoo Wiki on "Chroot from a livecd" "Changing root" or "chrooting" is a method for zooming in on part of your filesystem, so that, for example, /path will refer to what was formerly accessible at /mnt/path. The "root" in the expression "chroot" refers to the ...


20

For /proc and /sys, I suppose you could use either method. They are both special file systems so they can be recreated any number of times (the bind mount method uses the exact same mount as the host system, whereas the other method uses a new mount). I've always seen the bind mount recommended in guides, so I'd use that. As far as I know, there is no real ...


8

The Gentoo Handbook specifically calls out these two commands for re-mounting /proc and /dev. I've used them several times. mount -t proc none /mnt/chroot/proc mount -o bind /dev /mnt/chroot/dev I suspect /sys is just a regular folder, so you should be able to make a hard link. ln /sys /mnt/chroot/sys


7

You can't use symlinks, that is true. Symbolic links are relative to root directory (/), and in chroot that is chroot's root, not your filesystem root. Here's proftpd documentation page explaining the same thing.


6

A well-known problem in systemd distros (Arch Linux, OpenSUSE, Fedora). Systemd replaces sysvinit, and provides one great advantage over this. In sysvinit, when you ask a service to start, it inherits the execution context of the person invoking the script, which includes environment variables, ulimits, and so on. Systemd improves on this at the contrary ...


5

This would probably be more of a Serverfault question, but anyway. What I've done is to chroot my users to their home directories and then used mount --bind to create a link to it in their home directories. I then used setfacl to make sure www-data maintans write permissions on new files in the directory. This effect will recurse into /var/www, which is ...


5

On Linux – bind mounts. mount --bind /orig /vm/one mount --bind /orig /vm/two mount --rbind /media /vm/one/media Sharing /proc and /dev is the most common use for this (but make sure you use --rbind for /dev). You can even add -o ro for read-only. To make the mounts persistent, update /etc/fstab: /orig /vm/one none bind /orig /vm/two ...


4

The relevant section in the debian default bashrc is # enable programmable completion features (you don't need to enable # this, if it's already enabled in /etc/bash.bashrc and /etc/profile # sources /etc/bash.bashrc). if [ -f /etc/bash_completion ]; then . /etc/bash_completion fi The file sourced there is part of the bash-completion package: $ dpkg ...


4

Oh, I figured it out myself. Schroot has a feature called "sessions" where current environment can be preserved. Everytime one logs out without creating a "session", schroot brings everything to clean state and hence deletes the user as well. One can start a session using schroot -c mychroot -b


4

You would have a much easier time setting up a SAMBA share. (http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/install.html) The security protocols it supports are far more fine tuned and allows for setting up users and the lot. You can also set up groups to place users in if they are already preexisting. I would suggest it as a much better way ...


3

The solution is to edit the schroot configuration file at /etc/schroot/default/fstab. Just comment out the line of /home /home none rw,bind 0 0. If you run X you also need to uncomment the line for /run. All other configuration files are also at the same location.


3

Unfortunately, most programs do care about the kernel, both directly and not. Different operating systems have significant differences in even the most common features (epoll vs inotify vs kqueue, clone vs vfork vs rfork...). Even if the program sticks to minimal features that look the same to userspace (e.g. stdio, basic file access), it (or rather, the ...


3

this works for me with OpenSSH 5.1: set a restricted default for everyone, but let the staff group have the (unrestricted) defaults. Match Group *,!staff ChrootDirectory /home/ftp ForceCommand internal-sftp


3

SCREEN probably needs devpts, the pseudo-terminal filesystem, to be mounted on /dev/pts inside the chroot. mount -t devpts none "$rootpath/dev/pts" -o ptmxmode=0666,newinstance ln -fs "pts/ptmx" "$rootpath/dev/ptmx" (The newinstance flag is optional; it gives the user a completely separate pty list, preventing them from knowing what other users are ...


2

That is a reasonable thing to consider: other platforms, like MacOS-X, and applications, like Chrome, are using sandboxing to run whole applications or parts of applications in a way that they stop having full control equivalent to what you have. So, in answer to 1, yes, if you start an application running as yourself, it has equivalent access to what you ...


2

chroot does not magically change the running kernel or start a new one. It only changes how much of the filesystem "chrooted" programs see, but they still run inside the same kernel. Since Linux ELF executables cannot be run on Windows directly, chroot will not work. You can download your packages from https://www.archlinux.org/packages/ to disk, then ...


2

Not likely. You are already running a kernel. To have it load a second one based on a particular login doesn't sound possible or desirable. With the proliferation of virtualization tools these days, I would think that's a more likely solution.


2

Actually, there is a better workaround, that I found it schroot FAQ, in section Why is schroot overwriting configuration files in the chroot? By default, schroot copies over the system NSS databases ('passwd', 'shadow', 'group', 'gshadow', 'services', 'protocols', 'networks', and 'hosts', etc.) into the chroot. The reason for this is that the chroot ...


2

ashmem uses the /dev/ashmem device node. You need to create it in the chroot's /dev, either by using mknod with the apropriate numbers, or by doing a bind mount: touch chroot/dev/ashmem mount --bind /dev/ashmem chroot/dev/ashmem (You might need Busybox or Ubuntu's mount for this.)


2

This script may come in handy. http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/ looks like just enough to upload, download, rsync files, etc. I think you will then have to implement quotas to keep them from using too much disk space.


2

I stand by this answer, and I don't care if I got a -1 over it. This isn't something Unix can do for you in any reasonable kind of way. You're asking for something that's practically impossible. But there is sort of a way to get something like what you're asking for, kind of. Use a virtual machine. Set up an instance of the virtual machine for the user ...


2

To be sure that " everything inaccessible " behind this home directory, i would use chroot, but after you cannot do anything if you don't prepare the chrooted directory, you don't have any binaries or libs available. The configuration of FTP server can be useful for you : http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap29sec296.html ...


2

From the parent env, mount --bind /dev/shm /mnt/gentoo/dev/shm Or here's the invocation that we use for Gentoo Infra: echo /dev /dev/shm /dev/pts /proc /sys /run |xargs -n1 |xargs -I{} mount -o bind {} /mnt/gentoo/{}


2

For chroot to work, you also need to bind the kernels file systems, such as procfs, sysfs and /dev. To do this, you typically execute before chrooting: cd /path/to/chroot/destination mount -o bind /proc proc mount -o bind /sys sys mount -o bind /dev dev And only then you chroot into /path/to/chroot/destination. However, this is not equivalent to ...


2

The chroot command (or system call) changes the root directory for a specific process (or set of processes). So a process started as /home/user/bin/program could be chroot'ed to /home/user/. To the process /home/user would appear as / (the root directory), so it would be unable to access any files from directories above /home/user (and thus (arguably) making ...


2

Thanks for the hint :) The reason for this is the whoami dependency on nss to find users and groups. The solution I used was to strace the whoami call: / # strace /bin/whoami .... socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) ...


1

Option number 2 appears to be common practice (Live CDs by Ubuntu, remastersys iso-images and others appear to be designed like this). The image of the root partition is typically provided using squashfs. Using overlayfs and tempfs, the CD / DVD can be supplied with a writable appearance which supports booting a normal system. I've written a detailed guide ...


1

I you start yum from within the chroot, it will only look in myroot/etc/yum.repos.d. If you start it from the normal system, it will always look in /etc/yum.repos.d. So just start yum from within chroot. Of course you will first have to install yum and everything needed for it in the chroot.



Only top voted, non community-wiki answers of a minimum length are eligible