On Friday 27 March 2009 03:31:32 am Vincent Untz wrote:
Can we start talking about potential solutions instead of just talking
about the issues? :-)
We got to talk about both.
If you don't know there is an issue, you don't know that you need solution :-)
Le jeudi 26 mars 2009, à 16:08 -0500, Rajko M. a écrit :
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)
We can't assume that every user will want that ~Public exist  and for
majority that simply accept defaults it would be better to have this enabled
by default. As jdd said, it will be clear to almost anybody what is the
From "help desk" perspective it is easier to tell user: "Drop files that
want to share in ~Public, and pick it up on another computer".
(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
I can only agree.
There is no reason to create ability to make any directory shared. Moving
files in Linux is shorter than a blink within /home partition, so having one
directory Public is fine. That should be actually default configuration.
That is also problem with default samba.conf, it is revealing too much.
In this interface, there's a simple checkbox to
sharing. Checking the checkbox would:
It could be simple button like network icon in GNOME.
Press it and ~Public is visible. Press again and ~Public is off line.
Icon change indicates status.
+ use PackageKit to install potential missing
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
This can be done with pattern, something like Home Network. Although, I'm not
sure how to create one. Concept of patterns and their dependencies combined
with package dependencies is not for everyone.
+ use a YaST PolicyKit interface to properly
configure samba for simple
+ (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
When you mentioned PolicyKit, you finally lost me.
Why simple /etc/smb.conf as part of rpm would not satisfy basic needs.
Webdav is something that I never tried.
I tried public-html, but it doesn't work without fiddling with conf files.
- what is needed for security here? Should it make
between a computer on a local network and a computer directly
connecter to the world? What about wifi?
It should be difference. Local net is not the same as Internet.
Wifi is maybe different, but no one can defend home owner that leaves doors
open. All that distro has to do is to warn that door should be locked, tell
how to that and than user is on its own.
On the other hand, current status is like keeping door locked and key hidden
so far that one needs weeks to find it.
- 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?
I added my comments. Other should be free add more.
Now, what are we missing from the technical point of
And guess what? We can even use openFATE to continue
this discussion :-)
Just open an entry "Streamline file sharing configuration for simple
There are 2 I mentioned in previous post.
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org