The need to recreate secure_chroot_dir in /var/run/vsftpd when not using the supplied init scripts is not documented
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
vsftpd (Ubuntu) |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
Binary package hint: vsftpd
Ubuntu version:
Description: Ubuntu 9.10
Release: 9.10
Version of the vsftpd package:
2.2.0-1ubuntu1
Description of the problem:
By default, in /etc/vsftpd.conf, the secure_chroot_dir option is set to a directory inside /var/run/ (sorry I can't remember what is the actual directory, I've changed the value in my own vsftpd configuration file).
Even if the directory is created by a post install script, it is deleted each time the system is restarted on default ubuntu configuration since /var/run is mounted as a tmpfs filesystem , i.e. is only existing in RAM and thus is recreated at each startup.
A workaround I've found is to create a directory in any place which is not mounted in a tmpfs filesystem
(By default, tmpfs are used for /dev /dev/shm /var/run /var/lock /lib/init/rw)
summary: |
- secure_chroot_dir in /var/run/vsftpd disappears each time the system is - restarted + The need to recreate secure_chroot_dir in /var/run/vsftpd when not using + the supplied init scripts is not documented |
I'm not sure why this would be a bug. You change the default secure_chroot_dir to a directory that is under a tmpfs filesystem, so yes, it will be removed at every boot. If you stick with the default, the script will make sure it's created. If you change it (why?), you have to make sure you place it in somewhere that doesn't get cleaned up at every boot (or that you recreate it appropriately). I don't think the init script should parse the vsftpd configuration to cover that corner case ?