![](https://seccdn.libravatar.org/avatar/d79616993dab466bee3456e8ac46bfee.jpg?s=120&d=mm&r=g)
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