chroot
[OPTION] NEWROOT [COMMAND
[ARG]...]
chroot OPTION
Step 2
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
/sys is a virtual file system that interfaces with
the kernel. It is meant to replace /proc. More at
https://en.wikipedia.org/wiki/Sysfs
By the sounds of it, you have /mnt/sys mounted, try
umount /mnt/sys or better yet, reboot. If it is
doing this after the reboot, then arch-chroot is
probably has a typo, mount /sys /mnt/sys should be
mount --bind /mnt/sys. I could potentially help more
if you could post the output of mount. Not sure if
you have figured the solution out, as you posted it nearly a
month ago.
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 logged in.)
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
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 none bind,ro
Once you start with using bind mounts for VMs, you will soon find yourself deep in namespaces and containers. (For example, you can have a chroot with isolated network, with just a single command...) Take a look at lxc, which uses native Linux features to create virtual systems.
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.
When /home is mounted by schroot, all configuration files are placed in $HOME of the base install, irrespective of whether they belong to the schroot.
This can lead to configuration files being overwritten when two versions of a package are installed, one in the base install and the other in the schroot.
It's easy to alter the schroot setup so that its configuration files are placed in a different directory, as shown in the following example.
A schroot for wheezy-amd64 is located in /var/schroot/wheezy-amd64. This particular schroot is using the 'desktop' profile, hence its mount points are defined in /etc/schroot/desktop/fstab.
First, create a home directory for the user inside the schroot,
mkdir /var/schroot/wheezy-amd64/home/$USERNAME
Second, replace the following line in /etc/schroot/desktop/fstab,
/home /home none rw,bind 0 0
with,
/home /HOME none rw,bind 0 0
That's all! It's also convenient to add an alias to ~/.bash_aliases in the base install,
alias wheezy64='schroot -c wheezy-amd64 `/bin/echo "-d $PWD" | /bin/grep "^-d[ ]*\/home" | sed "s/home/HOME/"`'
Inside the schroot, the user now sees two home directories:
I found the answer. makejail program preserve permissions so there is no problem with jail directory created by makejail.
But deb helper scripts disturb every thing. on a default debian/rules file dh_fixperms run and change permissions so /bin/bash is not executable any more! to fix this problem we should overwrite dh_perms with this rule:
override_dh_perms:
every this get sweeter with this line!
I'm not sure I understand your Questions, but I will try to answer.
1) You can change the location of the users Home foler in /etc/passwd. Then create groups for the users who need to be able to read/write to these folders and
chown -R user:group /the/new/homefolder
1a) The problem with sftp is that the users will still be able to read other dirs and files on the system, but not write or create.
2) Again you could do as mentioned in 1,
3) I don't understand this part - do you mean switch user when logged in? You can normally do this by:
su username
And type in the users password.
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 -S /etc/bash_completion
bash-completion: /etc/bash_completion
Why did you switch from run-init to chroot? You shouldn't do that. run-init deletes everything in the initramfs root, then chroots to $rootmnt. You want to keep that behavior.
As for how to avoid having to manually rebuild your initramfs each time, edit the master copy of the init script in /usr/share/initramfs-tools. That should at least work until you upgrade the initramfs-tools package.
A permanent solution would be to patch the init script to recognize a boot argument to append something to rootmnt, and submit that patch for inclusion into debian. Then you can add the argument to grub for entries that should be booted that way.
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 forward than creating/restricting user accounts.
This would allow you to also entirely restrict them to their folder with no way out and it supports ftp (much more friendly).
Use ldd to check for linked libraries, e.g.:
$ ldd $(which whoami)
linux-vdso.so.1 => (0x00007fff00bfe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa25f48e000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa25f871000)
Don't worry if you can't find linux-vdso on your system, see e.g.:
The library that you see as linux-vdso.so.1 is a virtual library or Virtual Dynamic Shared Object, that resides only in each program's address space. Older systems called this linux-gate.so.1. This virtual library provides the necessary logic to allow user programs to access system functions through the fastest means available on the particular processor, either interrupt, or with most newer processors, fast system call.
1) Yes. 2) In general no. You have to trust at least some of the software that you run not to mess things up. 3) The easiest way would probably be to run the software as a different user. If it doesn't need access to anything, you could run it as the "nobody" user who has basically no rights. Otherwise, you could change the owner of all the files the application has to access to the user it runs as. Note that this would make accessing the files more difficult for you and other programs though.
In general, I wouldn't worry too much about it. You have backups of your data that you could restore files from anyway, don't you.
Run COMMAND
with root directory set to NEWROOT.
--userspec=USER:GROUP
specify user and group (ID or name) to use
--groups=G_LIST
specify supplementary groups as g1,g2,..,gN
--version
output version information and exit
If no command is given, run ’${SHELL} -i’ (default: ’/bin/sh -i’).
Copyright © 2012 Free Software Foundation, Inc. License GPLv3+:
GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute
it. There is NO WARRANTY, to the extent permitted by law.
Report chroot bugs to bug-coreutils[:at:]gnu[:dot:]org
GNU coreutils home page:
<http://www.gnu.org/software/coreutils/>
General help using GNU software:
<http://www.gnu.org/gethelp/>
Report chroot translation bugs to
<http://translationproject.org/team/>
chroot
The full documentation for chroot is maintained as a Texinfo manual. If the info and chroot programs are properly installed at your site, the command
info coreutils 'chroot invocation'
should give you access to the complete manual.
Written by Roland McGrath.