Re: [gnome-network]File sharing from Nautilus

[Daniel Brodie <daniel brodienet com>]

Thanks you for your reply

> Of course, as you say, this needs the user to know root's password

I don't think that the user needing to enter the root password as a
'once in a lifetime' scenario (like, as I said, initial configuration),
is bad. Currently, we even require the root password to set the time,
and this probably wont change anytime soon.

> > What happens behind the scene is that gst-network creates a shared
> > folder with the appropriate protocol in ~/.gnome-network/smb/ (or
> > whatever). Now when a user wants to share a folder a (symbolic?) link is
> > created to the folder in  ~/.gnome-network/smb/.
> >
> this seems to be similar to what Mac Os does, and makes it easier for
> users, since they don't need to know any extra password.

But macosx ships a tightly integrated system. If someone installs this
tool on thier system, there will have to be some initial configuration
as root. Otherwise, the program will take over my existing
smb/nfs/etc... configuration. This tool should work with exsisting
configurations.
Is macosx secure from this part if multiple users are logged in at the
same time?

> > This has the added plus of having the gst backends which will allow gst
> > to work for many distros and clients (do we really want to force people
> > to use a specific web client?).
> > 
> what do you mean?

This comment didn't really belong here. What I meant was that if the gst
way of abstracting the backend is used, there can be a large support for
diffferent distros and types of server. (a person could theoreticall
write a tftp share backend if he wanted to)
Also, you mean to sit atop already installed servers, and not run your
own minimal http server (or the sort), right?


> > Are these ideas even pratical?
> > 
> yes, they are. In fact, all solutions have their good and bad things, so
> I guess discussing deeply about each one would make us come to the best
> solution.
> 
> There are indeed other solutions mentioned on the thread in
> nautilus-list, like adding support to libsmbclient/samba to let normal
> users share directories. This seems to me the best solution so far. it
> would even be perfect if we could do the same for NFS, FTP, etc.
> Although, in this case (having to use 'n' libraries), maybe the
> system-wide daemon idea is a better solution.

Well, like I said earlier, I don't believe locking to a specific share
backend is good. There are many secutiry issues with smb, for example,
so letting the distro/root choose is a good thing.

The problem with having a system deamon is that:
a) it is a security risk. This could definiatly be done securly but it
is harder
b) Parsing and editing configuration files are a hacky thing as it is.
Having a deamon that constantly does it because the user that likes
clicking, could cause configuration file corruption. Especially, since
with most of these servers you usually have to restart the server for it
to take notice of the new settings. Not somthing you want to let the
user control, albeit indirectly.
c) How much control will a system administrator have over the
smb/http/ftp/nfs configuration files? Or will they be highjacked by the
system deamon?

Anyway, this will (and should) still require an initial login as root,
so that root can specify for this deamon, which users should be allowed
to do what.

well, after talking this over with a friend I believe the biggest
problem with a gst tool that just sets up the shares, before the users
share away, is how can the user get or send information?
1) When the user program wants to know if the user even has sharing
enabled. (or whatever, after all, a system administrator could want to
tweak these files by hand) And if so, what types of shares. 
2) How does the user tell the system that it wants to share a file? I
suggested earlier to use symbolic links, but those have a problem of
security issues. Many types of servers use chroot on the share for
security (I believe smb does), and the minute you have a symbolic link
to somewhere arbiturary, that security is gone. Using hard links is also
a problem, since if I understand correcty, if the system has quotas
enabled this will double the count for the user.
3) How can the user say wether it wants the files to be shared as r/w or
wether a user that wants those files should have anonymous access or a
seperate new username and password? The r/w access could be taken care
of by having a gnome-network user/group and having the user-space
program set the group of the file to gnome-network and then setting the
appropriate group permissions. This also means that all other users that
are part of the gnome-network group will have local access to the file,
even if the shared program is down (is this bad or good?).
The second part could be taken care of by having the user specify a
'shared' password, and then allowing two types of logins, an anonymous
login that uses the gnome-network user/group, and a 'full control' login
that uses the user's username and the shared password, and gives full
user access. I believe this is possible in smb, http and ftp, but not
sure about nfs and the rest?

Anyway, those are just some things off the top of my head.
Personally, I think the gst type tool is the way too go, bt I don't have
much experience in this matter.

Regards
-Daniel