Ok, so I was bored and I added very very basic HTTP support to vsftpd. vsftpd is now perhaps the only FTP server to have an option ftp_enable=NO. Basically none of the HTTP protocol is implemented, but it might suffice for someone who is super-paranoid and needs to serve some static files over the HTTP protocol. The selling point is the re-use of vsftpd's tried-and-tested listener, string handling and built-in sandboxing.
The bits live at ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.3.0pre1.tar.gz
I cannot use the name vshttpd, because bizarrely a Google search indicates it as taken: http://sourceforge.net/projects/vshttpd/. I do not know what the "vs" stands for in that case.
As usual, the feature will live or die depending on the level of user enthusiasm shown.
14 comments:
Please remove this feature. It damages the security profile of the software--its main selling point--by adding a feature (and surface area) that does not belong to a product with its stated purpose (vsftpd. It also makes it harder to sell to my bosses.
If you want to write a very secure httpd and use vsftpd's proven bits, break out those bits into a separate package and make the ftpd and httpd depend on it.
And if you're bored, please write a vssshd. What the world really needs an a sshd with support for non-system users (mainly for sftp-server).
Thanks for the comment, and nice use of bold to make your point :)
The HTTP support will always be off by default.
Off by default does not excuse it. It doesn't belong in vsftpd.
vsftpd achieved its fame by being the first really good ftp server: secure, fast, and secure. There are already a handful of good http servers. Don't dilute the cachet, reputation, and value of vsftpd on a whim.
It violates UNIX paradigma as I understood it.
"Do only one thing, but do it well"
vshttpd = very small
Don't listen to the critics, this feature is just fine.
Break the principles of UNIX is the most nonsensical idea at all. Many people condemn, non separate implementation. This program is losing its old users.
Break the principles of UNIX is the most nonsensical idea at all. Many people condemn, non separate implementation. This program is losing its old users.
epic fail
Hehe, love the responses. Maybe I should rename to vsdaemon and modularize it a bit? vsftpd could then be a separate binary from vswebdb (the name vshttpd is of course taken). The sandboxing, string parsing, listener, etc. are all inherently re-usable.
Where is option ftp_enable in vsftpd.conf, didn't find it ?
I like this new feature, it would fit very well the software needed for a mirror. Instead of having a httpd and ftpd serving the same files, you could have vsftpd doing both the jobs in a secure and fast way.
I don't think modularization would be useful though, kinda reminds me of microkernels and the like with their abysmal performance...
This software is useless. It doesn't even read my mail yet!
Jokes aside, a secure httpd could be very useful. There is a need for something with a clear, simple and secure design. There is publicfile and that's about it. (And perhaps gatling, which looks good to me.)
All else are either big opaque gobs of code, has had security problems, or has obvious ones. Some you have to jump through hoops just to get setuid and chroot.
Writing a httpd is however orders of magnitude more complex than an ftpd. As soon as you are past anonymous serving of static files (which in itself is an interesting niche, for where you use nginx or perhaps varnish today), you need to implement several authentication schemes, send non-RFC result codes to please buggy clients, do lots of address rewriting and talk CGI/FastCGI/SCGI. It's quite a handful.
Regarding if a monolithic server process, modules, or different daemons is the right choice I think what works best in practice is right. As long as you can choose not to include the unnecessary parts (compile- or run-time) most users will be happy.
@Chris:
Why not just contribute your bits to the Apache project where appropriate? vsftpd is used in our environment heavily for the robustness it provides.
@Loves your work said...:
-----March 18, 2010 7:13 AM
...What the world really needs an a sshd with support for non-system users (mainly for sftp-server).
-----
The world already has it! Well, something like it. For example, we use WebDAV over https (apache) to server large amounts of users and their files. And, if you want to support non-system users simply a flat file database for authenticating your users. Or, turn on SSL in vsftpd. Simple!
What do you think?
proper tag: NONSENSE!
as you might have figured out, many people support and rely on vsftpd. therefore, such huge coding decitions have to be made responsibly.
i think it's not a matter of splitting up into modules or re-using existing, well proven frameworks.
it's a matter of keeping things simple, fast, secure and in case of the code: READABLE.
if you start implementing further protocols like http, webdav, SMB or such, you definitely will need changes to the framework as well.
http authentication for example or https support and so on. the story will continue until you have something bloated.
remember, vsftpd was started because of only bloated, unreadable ftp daemons that support every broken client being available.
ftp is a very sophisticated procotol on it's own. if you really clean up your code, make things faster/better and smaller, i think you're gonna have work for years.
and if you're still bored, than nothing's better than to start off a new project, relying on vsftpd and being called vshttpd. no problem, but keep vsftpd as it is.
Post a Comment