vsftpd 2.3.5 adds additional security checks which complain when the root directory inside a chroot is writeable. While this is a legitimate concern, it has been an issue with chrooted systems since they began, and many installations knowingly balance that issue with convenience.
As such, the internet at large is in rebellion against this version of vsftpd - just search for "vsftpd: refusing to run with writable root inside chroot()", and the result are a pile of workarounds, from "compile your own" to "install the package from an earlier version of Ubuntu". These are suboptimal solutions in that it becomes too easy to forget that you manually installed some things and old and unpatched versions proliferate. When a release such as 12.04 has a 5 year support cycle, this is a recipe for disaster.
The vsftpd maintainers have added an "allow_writeable_chroot" option in later versions which bypasses this offending check. (I know it is in 3.0.0 at least). Either upgrading vsftpd in 12.04 to 3.0.0 or backporting this to 2.3.5 would be acceptable solutions - the latter likely being preferable.
Thank you for taking the time to report this bug and helping to make Ubuntu better.
In order to keep stable releases stable, updates after release are only considered under specific circumstances. Details of the process and of the criteria required are listed here: https:/
I understand that this makes it difficult for users of the LTS release to have writeable chroots, but now that the LTS is released and the fix doesn't meet the above criteria, I don't think this will change for 12.04. But note that the stable release updates team makes the decision on this by following the above policy and not me.
If you'd like a newer version of vsftpd to be made generally available for users who do want to use the "allow_
However, you can generally only backport after the development release of Ubuntu contains the version requested. I see that Debian unstable has vsftpd 3.0.2-1 now, and Ubuntu should merge this in a month or two, after the imminent release of Quantal. So a backport would take at least that long since we are in final freeze at the moment.
I appreciate the difficulty this causes and I regret that this can't be resolved sooner or just by updating the LTS. But I hope you understand that the LTS can only be kept stable if it is not modified to add features to minimise the risk of regressions.
Marking this bug as Invalid, as the request was to backport a feature to an existing release, which would violate SRU policy.
I'm not sure that we need a bug to track the merge of vsftpd from Debian sid, as this will happen in due course anyway. But once the next development release contains vsftpd 3 for the feature you need, please do go ahead and follow the backports procedure and file a backports bug against the Precise Backports project if you want to go down that route.