No more right click terminal

[John (J5) Palmieri]

On Sun, 2005-07-17 at 10:55 -0700, Jesse Keating wrote:
> 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 and security are not mutually exclusive.  Yes there are some
points that they are diametrically opposed.  

> 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.

Not to defend Linspire's track record but I don't think this is the case
anymore.

>   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.

Yes care needs to be taken and it is in the notion that the user share
would not be turned on by default and an admin could make it so a user
can not turn it on.

> > > 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?

As an admin of Fedora (I'm assuming you are one) you should get yourself
familiar with GConf.  It is basically a per user configuration database
that has key/value pair data in it.  Each key can be marked with a
default or mandatory value by the admin.  Defaults can be overrided by
the user, mandatory keys can not.  You would simply set the GConf key
for user-share startup to be mandatory false.  The cool thing about this
is you can use Sabayon http://www.gnome.org/projects/sabayon/ to do your
configuration without having to know much about GConf.  I assume you
test before you roll desktops out and like to keep the configuration
similar in such a highly secure environment.  Sabayon is an example of
usability increasing security.  I think you will appreciate it. 

> > > 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.

All valid points.

> > 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?

But of course this is your environment and it works well for you.  It is
not everyones.  Another note is that having the Public/Private folder
still does not prevent a user from accidentally pushing a file to Public
that should have been private.  Same issue with the user-share.
Ultimately the user needs to be somewhat responsible.  We do try to
prevent them from shooting themselves in the foot but we can't be
foolproof.

> > 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)?

No.

> > >  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?

No.

> > >  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.  

We do this, no change there.  The user needs to turn it 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).

Asking Joe user for root tends to be the wrong way to look at things.
If it is a managed environment then the sysadmin can make it so the user
can't turn it on and also not install the package.

-- 
John (J5) Palmieri <johnp at redhat.com>