On Thu, Feb 05, 2004 at 05:06:26PM -0600, Jeremy Enos wrote: > No reason why we couldn't do that. (it won't be in the "configurator" as > we now know it, due to the order of operations, but that's not > relevant) I'm fine w/ something like that and defaulting to "yes"... > however, could someone provide at least one solid reason not to simply > setup tftpd all the time? I'm sure we include other tools for a > catch-all/majority-use purpose, in spite of the fact that the user isn't > *guaranteed* to use them. What's the big deal here? Why busy the > interface?
Because tftpd is a massive security hole. Unauthenticated file access to the server is something that shouldn't be done to someone's machine without their knowledge. About a year ago you commented that it was pretty bad that we leave it on after install of nodes, so turning it on for people that don't ever need it seems *really* bad.
Maybe print the text in BIG RED LETTERS "READ THIS PARAGRAPH OR YOUR CLUSTER WILL NOT INSTALL" kinda thing.
If we're concerned about security of tftpd, I have a few comments.
* concerns are pertinent to the subset that elect not to use pfilter
* rsyncd is a MUCH greater hole, and it is and is going to continue to be on all the time
* both of these services can and should be tcp wrapped
* if we can't take steps to secure a running tftpd, we've got serious problems. We are apparently comfortable having it running on some (arguably most) clusters, then we need a security scheme good enough for all anyway
* It's not uncommon to have tftpd running all the time. You will find tftpd running on several large scale production systems (I'm not referring to NCSA's alone) as a necessity of design. This is not to mention any diskless system.
I've encountered both types of questions/complaints.
Complaint A: Hey... you guys just have tftpd on and waiting all the time and you didn't shut it off. I think that's sloppy and I didn't like that risk, so I had to shut it off myself.
Complaint B: Arrrgggghhh!!! I've been debugging my network, trying different NICs, and playing with for days, because they always hang at TFTP.... something. I guess I missed the "Setup Network Boot" step. This is so frustrating!!
Let me tell you that Complaint B is far more likely to cause someone to give up and abandon OSCAR. They're far more angry about it, and usually don't have a cluster installed yet. If we want to solve this with documentation, then document that they can shut it off. Our policy in the past has been to remove pitfalls if we can... protect the user from the user IF we can. Well, we can.
We start several daemons that have security risks (at least one that's much worse than tftpd) and we don't throw up a big red letter warning for each one. I'll repeat myself that this is *not* a big deal. The implications of a user accidentally missing the step to turn it on are worse and more widespread than those of having it running w/o needing it. That's not just my opinion; there's a history of user feedback to base it on. And we haven't even taken steps to secure it yet (assuming the non-pfilter case), which will only reduce Complaint A further.
btw- all this is moot in all cases except where floppy boot is used. I'm so tired of erroneously putting so much weight/emphasis on the fraction that still depends on floppies!!! Will it ever end?
Jeremy
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
