Hi all,
Im not sure is this is a security hole, but I have Ferdora Core 2 loaded on my machine and the vsftpd.conf shows: anonymous_enable=YES
If its Very Secure then surely anonymous_enable=NO allowing only local users to connect.
James Harrison
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Vsftpd by default allows anonymous connection to download and not upload so its ok.
Kashif Ali
----- Original Message ----- From: "James Harrison" jamesaharrisonuk@yahoo.co.uk To: "redhat fedora dev" fedora-devel-list@redhat.com Sent: Friday, September 10, 2004 4:43 PM Subject: vsftpd.conf
Hi all,
Im not sure is this is a security hole, but I have Ferdora Core 2 loaded on my machine and the vsftpd.conf shows: anonymous_enable=YES
If its Very Secure then surely anonymous_enable=NO allowing only local users to connect.
James Harrison
Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
And the anonymous user it is "chrooted" to an empty folder.
But i agree with the principe - don't ship with anonymous logon turned on - let the user do this if he/she wants to.
fre, 10.09.2004 kl. 20.35 skrev Kashif Ali:
Vsftpd by default allows anonymous connection to download and not upload so its ok.
Kashif Ali
----- Original Message ----- From: "James Harrison" jamesaharrisonuk@yahoo.co.uk To: "redhat fedora dev" fedora-devel-list@redhat.com Sent: Friday, September 10, 2004 4:43 PM Subject: vsftpd.conf
Hi all,
Im not sure is this is a security hole, but I have Ferdora Core 2 loaded on my machine and the vsftpd.conf shows: anonymous_enable=YES
If its Very Secure then surely anonymous_enable=NO allowing only local users to connect.
James Harrison
Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 2004-09-10 at 12:51, Kyrre Ness Sjobak wrote:
And the anonymous user it is "chrooted" to an empty folder.
But i agree with the principe - don't ship with anonymous logon turned on - let the user do this if he/she wants to.
This will break long standing behavior, besides, you still have to install vsftpd, and then manual start it and/or chkconfig it on, and enable incoming FTP in the default firewall.
It isn't as if all this will happen by accident.
Dax Kelson
On Fri, 10 Sep 2004, Dax Kelson wrote:
On Fri, 2004-09-10 at 12:51, Kyrre Ness Sjobak wrote:
And the anonymous user it is "chrooted" to an empty folder.
But i agree with the principe - don't ship with anonymous logon turned on - let the user do this if he/she wants to.
This will break long standing behavior, besides, you still have to install vsftpd, and then manual start it and/or chkconfig it on, and enable incoming FTP in the default firewall.
It isn't as if all this will happen by accident.
Totally agree. You'll need to configure the FTP server in any case, and you can just configure vsftpd for your tastes as well.
But i agree with the principe - don't ship with anonymous logon turned on - let the user do this if he/she wants to.
I agree too. User logins are OK but not anonymous.
--- Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
And the anonymous user it is "chrooted" to an empty folder.
But i agree with the principe - don't ship with anonymous logon turned on - let the user do this if he/she wants to.
fre, 10.09.2004 kl. 20.35 skrev Kashif Ali:
Vsftpd by default allows anonymous connection to download and not upload
so
its ok.
Kashif Ali
----- Original Message ----- From: "James Harrison" jamesaharrisonuk@yahoo.co.uk To: "redhat fedora dev" fedora-devel-list@redhat.com Sent: Friday, September 10, 2004 4:43 PM Subject: vsftpd.conf
Hi all,
Im not sure is this is a security hole, but I have Ferdora Core 2 loaded
on my machine and the vsftpd.conf shows: anonymous_enable=YES
If its Very Secure then surely anonymous_enable=NO allowing only local users to connect.
James Harrison
Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
On Fri, Sep 10, 2004 at 02:38:50PM -0700, James Harrison wrote:
But i agree with the principe - don't ship with anonymous logon turned on - let the user do this if he/she wants to.
I agree too. User logins are OK but not anonymous.
Well I disagree, that would break the existing setups. FTP is firewalled by default, so unless you explicitely turn off firewalling (for ftp) then there is no risk.
Daniel
You have a lot of faith in your firewall setup.
Why have a firewall rule to stop an anonymous someone ftping into the machine when you can either disable ftp altogether or stop that anonymous someone accessing the system and only allow known trusted users in.
Allowing anonymous ftp should be a special case.
--- Daniel Veillard veillard@redhat.com wrote:
On Fri, Sep 10, 2004 at 02:38:50PM -0700, James Harrison wrote:
But i agree with the principe - don't ship with anonymous logon turned on - let the user do this if he/she wants to.
I agree too. User logins are OK but not anonymous.
Well I disagree, that would break the existing setups. FTP is firewalled by default, so unless you explicitely turn off firewalling (for ftp) then there is no risk.
Daniel
-- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
_______________________________ Do you Yahoo!? Shop for Back-to-School deals on Yahoo! Shopping. http://shopping.yahoo.com/backtoschool
On Fri, 2004-09-10 at 23:49, James Harrison wrote:
You have a lot of faith in your firewall setup.
Why have a firewall rule to stop an anonymous someone ftping into the machine when you can either disable ftp altogether or stop that anonymous someone accessing the system and only allow known trusted users in.
Allowing trusted users in is even worse than allowing anonymous users (plain text authentication) in short: you shouldn't use ftp at all...
François
If youre going to be that paranoid, dont connect the machine to the internet.
James
--- "F. Kooman" fkooman@bromstraat.net wrote:
On Fri, 2004-09-10 at 23:49, James Harrison wrote:
You have a lot of faith in your firewall setup.
Why have a firewall rule to stop an anonymous someone ftping into the
machine
when you can either disable ftp altogether or stop that anonymous someone accessing the system and only allow known trusted users in.
Allowing trusted users in is even worse than allowing anonymous users (plain text authentication) in short: you shouldn't use ftp at all...
Fran�ois
Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
On Fri, Sep 10, 2004 at 05:09:44PM -0700, James Harrison wrote:
--- "F. Kooman" fkooman@bromstraat.net wrote:
Allowing trusted users in is even worse than allowing anonymous users (plain text authentication) in short: you shouldn't use ftp at all...
If youre going to be that paranoid, dont connect the machine to the internet.
Not really...I think he makes a very valid point that allowing trusted users to login via FTP is worse than allowing anonymous users FTP access. FTP should only ever be used in anonymous mode, like HTTP servers are mostly used for. If you don't what that, don't enable the service.
On Sat, 2004-09-11 at 06:42, Charles R. Anderson wrote:
Not really...I think he makes a very valid point that allowing trusted users to login via FTP is worse than allowing anonymous users FTP access. FTP should only ever be used in anonymous mode, like HTTP servers are mostly used for. If you don't what that, don't enable the service.
yes, it is best practise but how many companies use FTP on there internal network "in a controlled enviroment" to put data onto internal web/ftp/email etc servers. This number has to outway the number of companies running known anonymous ftp servers. Linux is being used more an more in internal company networks where anonymous ftp to servers would not be wanted.
/pt
... And if you want anonymous logins, you WILL notice it if it dont work. Same goes to user-logins. So why not simply disable both in the standard-config-file (effectively making the server unusable until someone have changed the config), and include comments telling how to enable it?
One common use case for non-anonymous ftp is file uppload to a web-hotel - as most users either dont know about or dont care about more secure ways. And those have mostly disabled ssh logins.
lør, 11.09.2004 kl. 11.39 skrev Paul Trippett:
On Sat, 2004-09-11 at 06:42, Charles R. Anderson wrote:
Not really...I think he makes a very valid point that allowing trusted users to login via FTP is worse than allowing anonymous users FTP access. FTP should only ever be used in anonymous mode, like HTTP servers are mostly used for. If you don't what that, don't enable the service.
yes, it is best practise but how many companies use FTP on there internal network "in a controlled enviroment" to put data onto internal web/ftp/email etc servers. This number has to outway the number of companies running known anonymous ftp servers. Linux is being used more an more in internal company networks where anonymous ftp to servers would not be wanted.
/pt
Why not take a BSD approach and give them the option when installing the package, say for example...
# rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N]
Copying relevant base configuration file.... Done.
Anonymous/User logins have been enabled if at a later date you would like to change this behaviour you can do so by editing /etc/vsftpd.conf
#
/pt
On Sat, 2004-09-11 at 21:13, Kyrre Ness Sjobak wrote:
... And if you want anonymous logins, you WILL notice it if it dont work. Same goes to user-logins. So why not simply disable both in the standard-config-file (effectively making the server unusable until someone have changed the config), and include comments telling how to enable it?
One common use case for non-anonymous ftp is file uppload to a web-hotel
- as most users either dont know about or dont care about more secure
ways. And those have mostly disabled ssh logins.
lør, 11.09.2004 kl. 11.39 skrev Paul Trippett:
On Sat, 2004-09-11 at 06:42, Charles R. Anderson wrote:
Not really...I think he makes a very valid point that allowing trusted users to login via FTP is worse than allowing anonymous users FTP access. FTP should only ever be used in anonymous mode, like HTTP servers are mostly used for. If you don't what that, don't enable the service.
yes, it is best practise but how many companies use FTP on there internal network "in a controlled enviroment" to put data onto internal web/ftp/email etc servers. This number has to outway the number of companies running known anonymous ftp servers. Linux is being used more an more in internal company networks where anonymous ftp to servers would not be wanted.
/pt
That would make script-based instalation impossible. So putting a script which ask questions during installation inside the rpm is a BAD idea.
søn, 12.09.2004 kl. 01.18 skrev Paul Trippett:
Why not take a BSD approach and give them the option when installing the package, say for example...
# rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N]
Copying relevant base configuration file.... Done.
Anonymous/User logins have been enabled if at a later date you would like to change this behaviour you can do so by editing /etc/vsftpd.conf
#
/pt
On Sat, 2004-09-11 at 21:13, Kyrre Ness Sjobak wrote:
... And if you want anonymous logins, you WILL notice it if it dont work. Same goes to user-logins. So why not simply disable both in the standard-config-file (effectively making the server unusable until someone have changed the config), and include comments telling how to enable it?
One common use case for non-anonymous ftp is file uppload to a web-hotel
- as most users either dont know about or dont care about more secure
ways. And those have mostly disabled ssh logins.
lør, 11.09.2004 kl. 11.39 skrev Paul Trippett:
On Sat, 2004-09-11 at 06:42, Charles R. Anderson wrote:
Not really...I think he makes a very valid point that allowing trusted users to login via FTP is worse than allowing anonymous users FTP access. FTP should only ever be used in anonymous mode, like HTTP servers are mostly used for. If you don't what that, don't enable the service.
yes, it is best practise but how many companies use FTP on there internal network "in a controlled enviroment" to put data onto internal web/ftp/email etc servers. This number has to outway the number of companies running known anonymous ftp servers. Linux is being used more an more in internal company networks where anonymous ftp to servers would not be wanted.
/pt
On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote:
Why not take a BSD approach and give them the option when installing the package, say for example...
# rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N]
Because RPMs are absolutely never ever supposed to ask questions.
- What if the RPM is being installed non-interactively? - What if the RPM is being installed with a GUI tool? - What if the user doesn't understand English?
And then you get into the general usability problems - are the question phrased properly? Is "Y/N" an appropriate prompt? etc.
Better to offer a nice GUI configuration utility and just let admins run it after the installation, or just edit the .conf file if they're of the mind.
Sean Middleditch wrote:
On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote:
Why not take a BSD approach and give them the option when installing the package, say for example...
# rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N]
Because RPMs are absolutely never ever supposed to ask questions.
- What if the RPM is being installed non-interactively?
- What if the RPM is being installed with a GUI tool?
- What if the user doesn't understand English?
And then you get into the general usability problems - are the question phrased properly? Is "Y/N" an appropriate prompt? etc.
Each rpm could then drop a scriptlet into a directory that gui would then be able to run to set things up for it.
/etc/system-setup/ vsftpd.py httpd.py samba.py kill_my_harddrive.py
And then the system-setup program would display the questions, get the answers... and possibly be able to bring the system into at least a bare-bones configuration.
Reset to original configuration [Yes] [No] [Help]
On Sat, 2004-09-11 at 17:38 -0600, Stephen J Smoogen wrote:
Sean Middleditch wrote:
On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote:
Why not take a BSD approach and give them the option when installing the package, say for example...
# rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N]
Because RPMs are absolutely never ever supposed to ask questions.
- What if the RPM is being installed non-interactively?
- What if the RPM is being installed with a GUI tool?
- What if the user doesn't understand English?
And then you get into the general usability problems - are the question phrased properly? Is "Y/N" an appropriate prompt? etc.
Each rpm could then drop a scriptlet into a directory that gui would then be able to run to set things up for it.
/etc/system-setup/ vsftpd.py httpd.py samba.py kill_my_harddrive.py
And then the system-setup program would display the questions, get the answers... and possibly be able to bring the system into at least a bare-bones configuration.
Reset to original configuration [Yes] [No] [Help]
Again, what if the configuration data isn't translated into the user's language? They end up getting some vital system configuration question they can't possibly answer? Why the heck does this *need* to be done at install time? If you are going to make a configuration tool, let the user run it them self after install.
It shouldn't be required to ask questions to get a "bare bones" setup. If you want a system that asks a bazillion questions on install time, doesn't guarantee they'll be translated, doesn't guarantee they'll be phrased intelligibly, and has tons and tons of infrastructure developed and maintained instead of just good configuration tools and intelligent defaults, you should install the OS produced over at http://www.debian.org.
For network services, there isn't any good reason at all for them to be enabled at install time. Have them disabled by default (Fedora/RHEL has a nice tool for enabling/disabling services even novices can use), and if the user doesn't like the defaults, they can change them. The .conf file is always there, and if that's Not Good Enough, a graphical tool that does a _lot_ more than ask some simplistic questions that probably don't cover many likely scenarios can be developed and delivered with the service.
What happens with new/inexperienced users that just Install Everything? They'll get all these questions they probably don't understand. They'll likely end up answering all sorts of questions (and there will be a hell of a lot of them too, if you add this infrastructure - look at Debian) they don't understand, providing answers that are not ideal for their situation, etc.
If the user needs the service, they can configure and enable it manually, and things will work for _everyone_ equally well.
-- Stephen John Smoogen | CCN-5 Security Team LANL SIRT Team Leader | SMTP: smoogen@lanl.gov Los Alamos National Laboratory | Voice: 505.664.0645 Ta-03 SM-1498 MS: B255 DP 10S | FAX: 505.665.7793 Los Alamos, NM 87545 |
Dont you love it when you mention something at 1am without properly thinking something through :)
However...
It shouldn't be required to ask questions to get a "bare bones" setup.
I don't think we should rule out the large majority of people coming over from other OS's, these people being the "I know what I want to do and why I want to do it, but don't quite know how to do it". Realistically how often would you install a tcp service and leave it at that.
How many times have you heard someone say "I installed Linux, now what do i do?"
Some people may like being asked questions while others do not, but it doesn't hurt to give people the option. There must be quite a few uses for more generalised post install package configuration tool which isn't just limited to vsftpd and this thread.
If you want a system that asks a bazillion questions on install time, doesn't guarantee they'll be translated, doesn't guarantee they'll be phrased intelligibly, and has tons and tons of infrastructure developed and maintained instead of just good configuration tools and intelligent defaults, you should install the OS produced over at http://www.debian.org.
Last time I used apt on debian from the command line i remember it saying something along the lines of "The following packages need to be configured before the can be used, would you like to configure them now", not only does it tell you they need to be configured it also gives you the option to help you do it, nor does it break automated installs. Just like everything else Debian has its place and also has a pretty good "bare bones" install itself.
I dont know why but not everyone likes trawling through man pages for half their waking day trying to get something to work.
On Sun, 2004-09-12 at 02:44 +0100, Paul Trippett wrote:
Dont you love it when you mention something at 1am without properly thinking something through :)
However...
It shouldn't be required to ask questions to get a "bare bones" setup.
I don't think we should rule out the large majority of people coming over from other OS's, these people being the "I know what I want to do and why I want to do it, but don't quite know how to do it". Realistically how often would you install a tcp service and leave it at that.
Who cares what other OSes do? If your reason is "other OSes do it," your reason, for lack of a better term, sucks. ;-)
How many times have you heard someone say "I installed Linux, now what do i do?"
"Documentation." ^_^
Some people may like being asked questions while others do not, but it doesn't hurt to give people the option. There must be quite a few uses for more generalised post install package configuration tool which isn't just limited to vsftpd and this thread.
Yes, actually, it *DOES* hurt people to give them the option. You have to ask questions about asking questions. You still end up with tons of questions that the user has no clue about or doesn't care about and, therefor, you get back answers that are most likely incorrect for what the user really wants. You add a lot of complication for little gain when other solutions exist.
If you want a system that asks a bazillion questions on install time, doesn't guarantee they'll be translated, doesn't guarantee they'll be phrased intelligibly, and has tons and tons of infrastructure developed and maintained instead of just good configuration tools and intelligent defaults, you should install the OS produced over at http://www.debian.org.
Last time I used apt on debian from the command line i remember it saying something along the lines of "The following packages need to be configured before the can be used, would you like to configure them now", not only does it tell you they need to be configured it also gives you the option to help you do it, nor does it break automated installs. Just like everything else Debian has its place and also has a pretty good "bare bones" install itself.
The debconf system has various priority levels for their questions. You are forced to answer a "what priority of question do you want to answer" question, and then lower-priority questions are ignored and a default answer is used. A number of packages, however, abuse this system heavily. The system also maps very poorly to a GUI. Packagers cannot craft a clean, usable GUI, but instead must specify questions in a rather abstract format so multiple frontends can handle it. They are forced to deal with a lowest common denominator that functions pretty poorly for every frontend.
The priority system is also entirely broken in concept. What is important to one use is trivial to another. Many packages which are merely dependencies have questions which must be answered, which especially is confusing when they are pulled in due to some completely unrelated package. (Yes, dependency chains *will* do that, when packagers don't break up their packages appropriately, or application authors make it impossible to break up the packages.)
When a novice user hits Install Everything, they get everything. Are they really expected to be able to answer all the questions that come up? Or do you expect the priority levels to give sensible defaults with the user being able to change things later? If you picked the latter (which you should've), then the question becomes, why the heck have the infrastructure to ask questions at install time anyhow, when you *already* have to ship a second solution and provide sensible defaults??
I dont know why but not everyone likes trawling through man pages for half their waking day trying to get something to work.
There are better forms of documentation than man pages. If you think the only options available are "ask questions at install" and "be a UNIX guru," you are failing to think of a ton of options in between.
Fedora/RHEL already have some great server configuration utilities. A new user just has to go to System Settings to find them. Tools exist for Apache and Samba at least, and I know quite a few others exist. More can be added. Along with good, clean, user-oriented documentation. These solutions help both users during the initial install *and* helps them down the road when they need to update or modify their settings.
Honestly, it isn't that much more "work" to install a package and click on its config utility than it is to install the package and have a half- assed config dialog popup. And the former solution solves far more problems in a much better fashion.
Who mentioned man here? Last time i edited vsftpd.conf, the comments provided me with more-than-enough information.
søn, 12.09.2004 kl. 04.05 skrev Sean Middleditch:
On Sun, 2004-09-12 at 02:44 +0100, Paul Trippett wrote:
Dont you love it when you mention something at 1am without properly thinking something through :)
However...
It shouldn't be required to ask questions to get a "bare bones" setup.
I don't think we should rule out the large majority of people coming over from other OS's, these people being the "I know what I want to do and why I want to do it, but don't quite know how to do it". Realistically how often would you install a tcp service and leave it at that.
Who cares what other OSes do? If your reason is "other OSes do it," your reason, for lack of a better term, sucks. ;-)
How many times have you heard someone say "I installed Linux, now what do i do?"
"Documentation." ^_^
Some people may like being asked questions while others do not, but it doesn't hurt to give people the option. There must be quite a few uses for more generalised post install package configuration tool which isn't just limited to vsftpd and this thread.
Yes, actually, it *DOES* hurt people to give them the option. You have to ask questions about asking questions. You still end up with tons of questions that the user has no clue about or doesn't care about and, therefor, you get back answers that are most likely incorrect for what the user really wants. You add a lot of complication for little gain when other solutions exist.
If you want a system that asks a bazillion questions on install time, doesn't guarantee they'll be translated, doesn't guarantee they'll be phrased intelligibly, and has tons and tons of infrastructure developed and maintained instead of just good configuration tools and intelligent defaults, you should install the OS produced over at http://www.debian.org.
Last time I used apt on debian from the command line i remember it saying something along the lines of "The following packages need to be configured before the can be used, would you like to configure them now", not only does it tell you they need to be configured it also gives you the option to help you do it, nor does it break automated installs. Just like everything else Debian has its place and also has a pretty good "bare bones" install itself.
The debconf system has various priority levels for their questions. You are forced to answer a "what priority of question do you want to answer" question, and then lower-priority questions are ignored and a default answer is used. A number of packages, however, abuse this system heavily. The system also maps very poorly to a GUI. Packagers cannot craft a clean, usable GUI, but instead must specify questions in a rather abstract format so multiple frontends can handle it. They are forced to deal with a lowest common denominator that functions pretty poorly for every frontend.
The priority system is also entirely broken in concept. What is important to one use is trivial to another. Many packages which are merely dependencies have questions which must be answered, which especially is confusing when they are pulled in due to some completely unrelated package. (Yes, dependency chains *will* do that, when packagers don't break up their packages appropriately, or application authors make it impossible to break up the packages.)
When a novice user hits Install Everything, they get everything. Are they really expected to be able to answer all the questions that come up? Or do you expect the priority levels to give sensible defaults with the user being able to change things later? If you picked the latter (which you should've), then the question becomes, why the heck have the infrastructure to ask questions at install time anyhow, when you *already* have to ship a second solution and provide sensible defaults??
I dont know why but not everyone likes trawling through man pages for half their waking day trying to get something to work.
There are better forms of documentation than man pages. If you think the only options available are "ask questions at install" and "be a UNIX guru," you are failing to think of a ton of options in between.
Fedora/RHEL already have some great server configuration utilities. A new user just has to go to System Settings to find them. Tools exist for Apache and Samba at least, and I know quite a few others exist. More can be added. Along with good, clean, user-oriented documentation. These solutions help both users during the initial install *and* helps them down the road when they need to update or modify their settings.
Honestly, it isn't that much more "work" to install a package and click on its config utility than it is to install the package and have a half- assed config dialog popup. And the former solution solves far more problems in a much better fashion.
Sean Middleditch wrote:
On Sat, 2004-09-11 at 17:38 -0600, Stephen J Smoogen wrote:
Sean Middleditch wrote:
On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote:
Why not take a BSD approach and give them the option when installing the package, say for example...
# rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N]
Because RPMs are absolutely never ever supposed to ask questions.
- What if the RPM is being installed non-interactively?
- What if the RPM is being installed with a GUI tool?
- What if the user doesn't understand English?
And then you get into the general usability problems - are the question phrased properly? Is "Y/N" an appropriate prompt? etc.
Each rpm could then drop a scriptlet into a directory that gui would then be able to run to set things up for it.
/etc/system-setup/ vsftpd.py httpd.py samba.py kill_my_harddrive.py
And then the system-setup program would display the questions, get the answers... and possibly be able to bring the system into at least a bare-bones configuration.
Reset to original configuration [Yes] [No] [Help]
Again, what if the configuration data isn't translated into the user's language? They end up getting some vital system configuration question they can't possibly answer? Why the heck does this *need* to be done at install time? If you are going to make a configuration tool, let the user run it them self after install.
Uhm.. this is what I am talking about with the 'system-setup program'. Maybe I was not too clear, but I think you are just looking for a fight. Not going to get one today sorry.
Sean Middleditch schrieb:
On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote:
Why not take a BSD approach and give them the option when installing the package, say for example...
# rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N]
Because RPMs are absolutely never ever supposed to ask questions.
- What if the RPM is being installed non-interactively?
- What if the RPM is being installed with a GUI tool?
- What if the user doesn't understand English?
And then you get into the general usability problems - are the question phrased properly? Is "Y/N" an appropriate prompt? etc.
Better to offer a nice GUI configuration utility and just let admins run it after the installation, or just edit the .conf file if they're of the mind.
Nobody set up a ftp server and leave the default config, so it doesn't really matter if anonymous logins are on by default or not.
søn, 12.09.2004 kl. 13.15 skrev dragoran:
Sean Middleditch schrieb:
On Sun, 2004-09-12 at 00:18 +0100, Paul Trippett wrote:
Why not take a BSD approach and give them the option when installing the package, say for example...
# rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N]
Because RPMs are absolutely never ever supposed to ask questions.
- What if the RPM is being installed non-interactively?
- What if the RPM is being installed with a GUI tool?
- What if the user doesn't understand English?
And then you get into the general usability problems - are the question phrased properly? Is "Y/N" an appropriate prompt? etc.
Better to offer a nice GUI configuration utility and just let admins run it after the installation, or just edit the .conf file if they're of the mind.
Nobody set up a ftp server and leave the default config, so it doesn't really matter if anonymous logins are on by default or not.
... exept those noobs who just hits "install everything" (which amounts to 50% of n00bs comming straight from the bare-bones windows world). There should be a "install everything, exept servers" option in anaconda...
BTW asking questions during install caused me a lot of trouble when macromedia flash plugin did this - i was rolling it out to a number of machines using admin-script (www.solution-forge.net/source/unprotected) (the protected folder is empty ;) ). Thank you dag for providing a no-questions-asked rpm.
But if nobody installs a ftpd without confing it, what bad would it do to disable logins?
On Sun, 12 Sep 2004 13:54:36 +0200, Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
But if nobody installs a ftpd without confing it, what bad would it do to disable logins?
What bad would it be if http came completely unconfigured? Or if sshd came completely unconfigured?
Its not unreasonable for a service to come configured to do something, as soon as its in enabled. The subtle and competent use of reasonably sane defaults to provide commonly used reasonable safe(relative to the purpose and scope of the service being started) and consistent functionality is an art. In the case of ftp, password protected logins by default are just completely unsafe becuase ftp uses clear text authentication. That is clearly and utterly irresponsble if enabled by default, such a feature relies heavily on the network its exposed to being "trustable."
We can debate, forever, whether its reasonably safe to enable anonymous user access by default for ftp. But to leave anon login for ftp unconfigured by default, that sets a precedent, to leave every service completely unconfigured to do NOTHING by default. And thats just not a reasonable expectation. If sshd can come preconfigured to do something, and httpd can come ccnfigured to do something... vsftpd can come configured to do something by default as well. And for ftp, the very restricted anonymous access vsftpd allows, seems a relatively safe option compared to all the other default configured to do something options for ftp.
The bulk of this discussion is completely uninteresting.. but there have been hints about how to extend the functionality of system-config-* for more and more services. It would be interesting to see if there is any interest to extend firstboot in some way to be aware of each service package that was installed, and to think hard about the ui of presenting users with a list of services that are available and whether to enable it and maybe an option to configure each service that has a system-config tool associated with it.
-jef
Better to offer a nice GUI configuration utility and just let admins run it after the installation, or just edit the .conf file if they're of the mind.
Nobody set up a ftp server and leave the default config, so it doesn't really matter if anonymous logins are on by default or not.
Incorrect. That should read, "Nobody SHOULD set up an ftp server and leave the default config...". Unfortunately a lot of people who don't have a clue do this exact thing, and allowing anonymous ftp logins by default may be a security issue for these people.
I agree that a nice configuration utility would be nice and to just let the admin edit the config to his/her liking, but leaving anonymous logins off only requires an extra line in the release notes and a small paragraph in any manual. I think this is a small price to pay for the potential benefits.
Brandon
-- Brandon Joseph Adams Email: bja@illinois.dyndns.org AIM: Ace50003
Hi,
Has anyone looked at proftpd an alternative to vsftpd (http://proftpd.linux.co.uk) ?
It appears that it has a provision for ssl.
No more need for clear text passwords......
James
--- Brandon Joseph Adams bja@illinois.dyndns.org wrote:
Better to offer a nice GUI configuration utility and just let admins run it after the installation, or just edit the .conf file if they're of the mind.
Nobody set up a ftp server and leave the default config, so it doesn't really matter if anonymous logins are on by default or not.
Incorrect. That should read, "Nobody SHOULD set up an ftp server and leave the default config...". Unfortunately a lot of people who don't have a clue do this exact thing, and allowing anonymous ftp logins by default may be a security issue for these people.
I agree that a nice configuration utility would be nice and to just let the admin edit the config to his/her liking, but leaving anonymous logins off only requires an extra line in the release notes and a small paragraph in any manual. I think this is a small price to pay for the potential benefits.
Brandon
-- Brandon Joseph Adams Email: bja@illinois.dyndns.org AIM: Ace50003
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
On Sun, 12 Sep 2004 11:11:00 -0700 (PDT), James Harrison jamesaharrisonuk@yahoo.co.uk wrote:
Has anyone looked at proftpd an alternative to vsftpd (http://proftpd.linux.co.uk) ?
It appears that it has a provision for ssl.
No more need for clear text passwords......
So does vsftpd via openssl(though there are of course licensing issues associated with openssl which make adding for support for gnutls attractive). I won't bother giving you the faq url or the quote from the vsftpd manpage outlining that. I'll leave that as an excercise for the reader.
But thats not the point... the point is a sane default that provides reasonable commonly expected functionality when the service is enabled in a reasonable safe fashion. Tradeoffs must be made between security and functionality and usability. Reasonable defaults find the balance. Reasonable.... that's a word that can't be stressed enough. Let's talk about reasonable for a minute.... I don't see anyone using the same arguments to say that httpd should come configured by default to ONLY do encypted authenticated based access. I wonder why that is? There is an expectation that httpd should come enabled by default to allow unencrypted public access when its enabled. Thats a reasonable expectation, considering http's widespread use as a public anonymous way to retrieve information. And i think the same expectation can be reasonable applied for default ftp server behavior, to enable anonymous public access to data. Both http and ftp can be configured for different purposes...but we are talking about reasonable defaults that strike the balance. And I for one find it...unreasonable...to talk about ftp's anonymous default access like its a special case situation, when no one is making the same arguments to lockdown httpd's default configuration.
-jef"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. --George Bernard Shaw"spaleta
On Sun, 12 Sep 2004 00:18:37 +0100, Paul Trippett paul@icdw.co.uk wrote:
Why not take a BSD approach and give them the option when installing the package, say for example...
# rpm -i vsftp....rpm Would you like to enable Anonymous logins? (y/n) [N] Would you like to enable Local user Logins? (y/n) [N]
Copying relevant base configuration file.... Done.
nope
rpm packages as a design goal should be installable in an automated fashion packages that demand any interactiveness...are suboptimal across a wide range of situations. If you had ever done a kickstart install, would have never suggested this.
-jef