On Sun, 2005-07-17 at 11:36 -0400, Colin Walters wrote: > Sigh...I'm amazed that people react so violently to something I think is > so obviously useful. I'll answer your email in reverse order: Useful or not, I have never liked the idea of more file serving things I have to hunt for and turn off. In a corporate environment with sensitive data I absolutely cannot have any file sharing system that is unauthenticated. Useful comes at a price, and most often that price is lowered security. Usability is most often a fine line struck between ease of use and security of the system. Some distros are much 'easier' to use because they sacrifice security for usability. Lindows (or whatever it is now) is like that. Every user is root so making changes to the system is very 'easy' as well as sharing files w/ other users on the system. Of course, I hope any sane person shudders at the idea of every user being root. Thats like... XP Home. Now I'm not comparing Fedora to XP, I'm just hoping that you realize that usability comes at a cost and when that cost is Security, extreme care must be taken to how this usability is used and managed. > > I strongly object this EVER making it into core without some > > administrative method of restricting access or the ability to 'turn it > > off'. > > I believe startup is keyed off a GConf preference. When we integrate it > into the upcoming GNOME session services framework the GConf-keying > should happen automatically. I'm afraid I lack the knowledge of GConf to understand this statement. Do you mean that it will default to off? > > Heck, I'd rather not see it there period. User workstations are > > not for sharing files. A file server is designed and useful for that. > > The sysadmin in my shudders w/ terror. > > Right, so next time I go to a coffee shop with a friend and want to > share files, we'll just haul along my enterprise file server... My users would be fired if they opened up a unauthenticated share in a coffee shop. Scp, usb fob, https w/ authentication, something along those lines. Not everybody works in an environment where it is OK if somebody outside the company gets a hold of source code that is being worked on. > Seriously, even at work at Red Hat's Westford office where we do have a > file server it's been really useful. I don't use the file server > because the normal usage requires I have a NFS home directory, and NFS > sucks with laptops. I want to be able to unplug my laptop and go. We don't use NFS home dirs for that reason as well. We actually use Samba is it allows for much better security and flexibility with file ownership and quotas on the file server itself. It becomes just an icon on the desktop or another item in Computer to get to the file server. There are public read/write directories (still requires an authenticated user to the samba server to see them), read-only user directories and a Private/ directory within user's directories that are viewable only by that user. It is very easy for a user to drag a file to the appropriate folder and tell the other use to find it there. Then it gets backed up too, so that when the user drops their laptop and fags the disk, we have a copy of their files. They didn't just leave it in their home directory because everybody could find it there, why put it anywhere else? > It's significantly easier for me to drag and drop a patch into my > ~/Public directory and tell my coworkers to find it on > "Computer->Network->walters' Files" than it is to scp it to the file > server, and have them (likely) scp it off. > > I might also note it's also more efficient in terms of network usage. It is also easier and more network efficient for some folks to keep using telnet to access remote systems. This does not make it better or desired in a large amount of areas. > On to your technical questions: > > > Er, what protocol does this use to share? > > HTTP; it runs Apache as your user. What port then? Will the system 'automatically' open this port on the user configured firewall, because the system thinks that it should be open (much like cups)? > > What authentication methods > > are there? > > None, the idea is the files are public. > > > What ports does it use? > > It's dynamically bound and announced via Rendezvous. Ok, that answers my above question and scares the crap out of me. I'll ask again. When dynamically bound will it take it upon itself to open said port on the firewall? > > Why would there suddenly be a > > publicly viewable folder WITHIN MY HOME DIR?! > > Isn't that what many installations of Apache have done for years with > ~/public_html off your file server? This also required changing the default permissions on /home and your /home/foo directory. Very very bad juju there as well if it were a shared system. I guess bottom line is that this technology might be useful in some environments. However it poses a (IMHO severe) security risk in many other environments and I'd like to see Fedora continue the train of thought to turn off potentially security risky services by default and make the user make a conscious decision to turn the service back on. I also hope that any UI designed to manage this service requires a root password so that joe user couldn't override an administrative setting to disable this service (especially if it fiddles w/ the firewall once enabled). -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
