No more right click terminal

[Jesse Keating]

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