Bug 8852 - Net usershare command causes obsolent share definitions
Net usershare command causes obsolent share definitions
Status: RESOLVED INVALID
Product: Samba 3.6
Classification: Unclassified
Component: Client Tools
unspecified
All All
: P3 major
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-10 12:16 UTC by Julien
Modified: 2012-05-04 04:20 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julien 2012-04-10 12:16:02 UTC
The following bug has been experienced useing the nautilus share extension, which relys on the "net usershare" command:


When e.g. deleting (or renaming, moving) a folder that has been shared (via
contextmenu) the share definition in /var/lib/usershares won't be deleted (or
modified in case of renaming, moving).
This causes obsolent share definitions, which may cause the sharing icon of all
shared folders to disappear, if the result of "net usershare info" ends with an
error message, which is the case whenever the alphabetically last share
definitions is obsolent/corrupt. (Exception seems to be shares that begin with
the letter "a". Shares that begin with "a" are always listed last)


This Bug affects all Distributions using "net usershare" (testet on Ubuntu 10.04 and
Ubuntu 12.04 beta-2 as well as  the current Debian stable release.)


This is a possible security problem:

The obsolent share definitions has to be removed, because creating a new folder
with the same name of a once shared (and then deleted) folder will
unintentionally share the new folder as well. Furthermore it is important that
the sharing icons won't disappear, so user will still see that a folder is
shared. Both problems can lead to security risks and since the bug affects
probably all distributions who use nautilus, the problem is major.
Comment 1 Volker Lendecke 2012-04-24 19:30:28 UTC
What is Samba supposed to do here? The only thing we can do is to ignore those usershares that have no direcories behind them. We have code for that, so those orphaned usershares should never show up in a share listing.

Even if we deleted those usershare files that are invalid in this sense, this will not catch the race condition you mention. We have no way to find out whether the usershare definition matches the directory that the user intended to share.

I'm closing this as invalid as seen from the Samba side. Please re-open if you have a solid suggestion how to fix this properly.
Comment 2 Julien 2012-05-02 21:26:01 UTC
>> What is Samba supposed to do here? The only thing we can do is to ignore those
>> usershares that have no direcories behind them. We have code for that, so those
>> orphaned usershares should never show up in a share listing.

The problem of the disappearing sharing icons is going to be fixed, did I get that right?


>> Even if we deleted those usershare files that are invalid in this sense, this
>> will not catch the race condition you mention. We have no way to find out
>> whether the usershare definition matches the directory that the user intended
>> to share.


When starting nautilus, the usershare command notices the invalid directory and therefore responds with the error message. Instead of just ignoring the error, the share definition should be deleted.
This would solve the issue after reboot (which would help in most cases).
Of cause it doesn't solve the bug itself, but I think it would be the best workaround.



Idea for a final solution:

Instead of just defining the path of the shared folder, there could be something aside which would define the share definition as unique.
For example the creation date.
So even if I share a folder and delete it afterwards, I could make a new folder with the same name which would not be shared automatically.
After rebooting the obsolent share definition will be deleted.
Comment 3 Volker Lendecke 2012-05-03 13:01:01 UTC
Please provide exact steps with just the net usershare and other file system commands (no nautilus magic please) to recreate the problem.
Comment 4 Julien 2012-05-03 21:38:04 UTC
Creating usershares:

gnomeuser@gnomeuser:~/Desktop/test$ mkdir /home/gnomeuser/Desktop/test/{bb,gg,pp}
gnomeuser@gnomeuser:~/Desktop/test$ net usershare add cc '/home/gnomeuser/Desktop/test/bb' 

gnomeuser@gnomeuser:~/Desktop/test$ net usershare info
[cc]
path=/home/gnomeuser/Desktop/test/bb
comment=
usershare_acl=Everyone:R,
guest_ok=n

gnomeuser@gnomeuser:~/Desktop/test$ net usershare add ww '/home/gnomeuser/Desktop/test/gg'
gnomeuser@gnomeuser:~/Desktop/test$ net usershare add ff '/home/gnomeuser/Desktop/test/pp'
gnomeuser@gnomeuser:~/Desktop/test$ net usershare info
[ff]
path=/home/gnomeuser/Desktop/test/pp
comment=
usershare_acl=Everyone:R,
guest_ok=n

[cc]
path=/home/gnomeuser/Desktop/test/bb
comment=
usershare_acl=Everyone:R,
guest_ok=n

[ww]
path=/home/gnomeuser/Desktop/test/gg
comment=
usershare_acl=Everyone:R,
guest_ok=n

When creating usershares like this (via terminal), the sharing icons won't appear until nautilus is restarted (respectively a specific command, which I don't know, is executed)


gnomeuser@gnomeuser:~/Desktop/test$ ls
bb  gg  pp

gnomeuser@gnomeuser:~/Desktop/test$ mv gg ggg
gnomeuser@gnomeuser:~/Desktop/test$ ls
bb  ggg  pp

gnomeuser@gnomeuser:~/Desktop/test$ net usershare info
[ff]
path=/home/gnomeuser/Desktop/test/pp
comment=
usershare_acl=Everyone:R,
guest_ok=n

[cc]
path=/home/gnomeuser/Desktop/test/bb
comment=
usershare_acl=Everyone:R,
guest_ok=n

info_fn: file /var/lib/samba/usershares/ww is not a well formed usershare file.
info_fn: Error was Path is not a directory.

After restarting nautilus, all sharing icons will disappear.

The sharing definition is still there:

gnomeuser@gnomeuser:/var/lib/samba/usershares$ cat ww
#VERSION 2
path=/home/gnomeuser/Desktop/test/gg
comment=
usershare_acl=S-1-1-0:R
guest_ok=n
Comment 5 Julien 2012-05-03 21:57:56 UTC
I don't know how this is related, but;

When sharing one of the default folders in the home directory (which all have special icons from the beginning), the sharing icon of only the specific shares folder will also disappear after restarting nautilus. All other shared folders will keep their sharing icons in this case. 
This does not affect shared folders with normal emblem icons.
Comment 6 Volker Lendecke 2012-05-04 04:20:38 UTC
Ok. This is a nautilus problem. The last step printing the error message prints that error to stderr, the valid shares are listed on stdout. Again, I think Samba just behaves correctly. Just tested this.

Regarding the disappearing icons: Samba does print out a list of the remaining valid shares. Why nautilus does not display them is up to nautilus. I also tested smbclient -L against the different situations: smbd lists the valid shares even when there are invalid ones.

Regarding the second point with uniqueness of directories: Yes, we could narrow the race a bit, but we can not close it completely. Inodes can be re-used and most systems don't have an inode birthtime.

Closing as invalid again, there is nothing we can do here.