Tag Info

New answers tagged

1

I met the same issue and found the solution. You need to set the setuid root to the schroot executable file. The step is shown below. cd /usr/bin sudo chmod 4755 schroot enjoy it.


0

Solution: Can't use a symlink inside the chroot. Add to your rc.local, to run in boot: $ cp /etc/resolv.conf /var/named/chroot/etc/resolv.conf This ensures that chrooted bind can use the name servers amazon assigns during cloud init. It will have no problem resolving dns within the chroot.


0

make sure the following is in your vsftpd.conf userlist_deny=YES Then make sure root is in /etc/vsftpd/user_list Restart vsftp and it should deny root login


1

For your specific situation, a chroot is useless. While a docker container is less secure than a fully-emulated VM, docker is still significantly more secure than a plain chroot. So, if you have a user who is capable of breaking out of docker, a straight-up chroot isn't going to slow them down. That being said, there is a way to do what you describe: ...


0

I'm unsure if this 100% correct, since I never found the documentation describing this feature being limited to local users, but apparently vsftpd doesn't allow anonymous users to write in their chroot directory with the allow_writeable_chroot=YES directive. You have to either create a sub-folder with write permissions for anonymous users or allow local ...


0

either do the both other answers (downgrading, or reducing security by disabling the check) Another option would be to actually fix the issue by having correct permissions for the root chroot folder. Qouting a nice blogpost, which Marek already linked – Add stronger checks for the configuration error of running with a writeable root directory inside ...


0

Apparmor and bind9 have some conflicts with Plesk. Edit the file /etc/apparmor.d/local/usr.sbin.named and add: /var/named/run-root/** rwm, Reload and restart: service apparmor reload service bind9 start Now everything should work properly.



Top 50 recent answers are included