Re: [gnome-network]File sharing from Nautilus

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2003-08-26 at 17:55 -0400, Daniel Brodie wrote:
> 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.
> 
yes, right. If we use something like what RH uses, the user only needs
to enter the password once. I'm not sure, but I think gnome 2.4 includes
this.

> > > 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?
> 
don't know, since I don't use it. Can somebody with a mac explain us in
detail how is this done?

> > > 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?
> 
yeah. Running our own server makes things very tricky, since you can't
have more than user running the server, due to using the same port (or,
if you don't use the same port, then, it's a mess, since users need to
know which port other users are using).

> 
> > > 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.
> 
no, I don't think so neither. The best thing is if we can integrate with
all networks (smb, nfs, novell, etc).

> 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
>
yes, but in any case, there are plans to have such a daemon, not only
for this, but for things like knowing when a network card has been
started/stopped, etc

> 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?
> 
well, like GST, that daemon should just integrate, not replace other
means to access that file.

> 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. 
>
there must be a way to know it, yes, so that we can disable/enable the
menu item in the nautilus context menu, for instance.

> 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.
>
if we use the daemon, we just have to send a message to it, to tell it
'share this folder for user x'. If no daemon, then I guess using
symbolic links, or, if not possible, a synchronized copy (we could use
fam on the server to detect when there are changes on the dirs being
shared, and sync the copy when this happens) might work.

> 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?
> 
yes, we need more detail on the setting on a shared dir.

> 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.
> 
I'm not sure yet, although yes, seems so far, the best solution.

Anybody has any more comments?

cheers