Mailinglist Archive: opensuse-project (441 mails)

[James Tremblay aka SLEducator <fxrsliberty@xxxxxxxxxxx>]

Alberto Passalacqua wrote:
> All this is interesting, but how do we manage that in a transparent way
> in both DE's? Shares in KDE are managed by KDE itself too, which comes
> with its samba configuration tools, which are not integrated with YaST.
>
> Plus, I'm not amazed by the idea of having a public and accessible zone
> on a default installation. The current behaviour in GNOME is good enough
> imho, and the user has to follow the same path it follows on Windows.
>
> The actual problem is not in the interface, but in samba setup, mainly
> due to the firewall. If you setup samba server in YaST, it actually
> works almost out of the box, if the firewall is setup correctly. So I
> think it is not necessary to redesign the whole interface, create
> dependencies between YaST and other tools and so on, at least as a first
> approach. A cleaner guided procedure to configure samba server and the
> firewall, with the possibility of invoking YaST from the DE GUI to do to
> the job should be OK, safer, and easier to maintain on the long run.
>
> Regards,
> A.
>
> Il giorno ven, 27/03/2009 alle 09.31 +0100, Vincent Untz ha scritto:
>   
> > Hey,
> >
> > Can we start talking about potential solutions instead of just talking
> > about the issues? :-)
> >
> > Example:
> >
> > Le jeudi 26 mars 2009, à 16:08 -0500, Rajko M. a écrit :
> >     
> > > Sharing files:
> > > That means at least one directory is shared. You can drop content without 
> > > knowing any options, touching any button, adding any users, enabling any 
> > > ports, and pick that from another computer. I'm sure that will expose all 
> > > Samba vulnerabilities to LAN, but seriously, since when is Home LAN 
> > > considered war zone? 
> > >       
> > The user goes in ~/Public with his file manager displays a button
> > "Enable file sharing" for this specific directory. The user clicks on it
> > and the file sharing preferences are opened. (or the user directly looks
> > in the preferences and finds "File Sharing" there)
> >
> > (alternatively, we can just keep the right-click and "Share" menu item
> > for each directory and live happy with it, but I tend to think it's a
> > broken way to share files and prefer to have everything in ~/Public --
> > this is of course debatable and this is not the immediate object of this
> > mail)
> >
> > In this interface, there's a simple checkbox to enable/disable file
> > sharing. Checking the checkbox would:
> >
> >  + use PackageKit to install potential missing packages (installing
> >    samba for sharing via smb and apache for sharing via webdav -- most
> >    people won't care about which one is used, this can be an advanced
> >    user option)
> >  + use a YaST PolicyKit interface to properly configure samba for simple
> >    file sharing
> >  + (no need to do anything as root for webdav since a simple webdav
> >    server can be run with apache as the user)
> >  + use a YaST PolicyKit interface to open the right ports in the
> >    firewall
> >    - what is needed for security here? Should it make a difference
> >      between a computer on a local network and a computer directly
> >      connecter to the world? What about wifi?
> >    - for samba, this is a one-time effort
> >    - for webdav/apache, this is opening a port per ConsoleKit session
> >      (so it should be closed when the ConsoleKit session is closed, and
> >      maybe permission should be asked on next session opening if we're
> >      in a strict policy environment)
> >
> > Is this workflow missing something?
> >
> > Now, what are we missing from the technical point of view:
> >
> >  + we have file sharing preferences
> >  + we have PackageKit
> >    - we don't have the information "this package is needed if you want
> >      to enable this specific feature" (this could arguably be
> >      hard-coded, or we could use RPM Provides)
> >  + there's an effort to offer a PolicyKit interface to YaST. No idea
> >    what is the status of that and if it allows high-level operations
> >    like the ones described above.
> >    - if samba is already configured on the system, but on a different
> >      way, can YaST detect that and do the right magic to add the
> >      configuration that would be needed?
> >  + I doubt we have anything that can link a specific firewall rule to a
> >    ConsoleKit session at the moment. Is this a good solution (I think it
> >    could be)? How can it be implemented?
> >  + this should be discussed from a security point of view too. If we agree
> >    this is what we want to do, which operations are safe to do without a
> >    password? Which ones require a password? Do we need some specific
> >    text when asking the password explaining the security implications?
> >
> > And guess what? We can even use openFATE to continue this discussion :-)
> > Just open an entry "Streamline file sharing configuration for simple
> > user case".
> >
> > Vincent
> >
> > -- 
> > Les gens heureux ne sont pas pressés.
> >     
>
>   
we created a bug a while back that asked for a more simplified way to
become a
Samba "work group" server. The reason was that there are a lot of
settings to becoming
a "good" windows server (saying it even tickles) there should probably
be a quick way to
setup a "samba" client based on a person clicking the "network" link in
Nautilus.
A simple "Would you like to find a Windows Work group?" y/n
"Would you like to join a Windows Domain?" y/n
and then launch YaST or Nautilus could just do what it does now,
Continue to fail on Joe Plumber and
piss him off. He doesn't have nor does he want firewall training! Samba
set up training! he just wants to click ,answer questions and go to
"work".  Joe Plumber is an IT moron but he spends money on computers ,
i  want my share and so Does Novell.

-- 
James Tremblay
Volunteer openSIS Product Specialist
http://www.os4ed.com
e-mail james "at" os4ed.com
e-mail sleducator "at" opensuse.org
CNE 3,4,5
MCSE w2k
CLE in training
Registered Linux user #440182
http://en.opensuse.org/education


begin:vcard
fn:James A Tremblay
n:Tremblay;James A
email;internet:SLEducator@xxxxxxxxxxxx
tel;work:james@xxxxxxxxx
x-mozilla-html:FALSE
version:2.1
end:vcard