files incoming through nautilus-share should be created with user ownership, instead of "nobody"

[Felipe Figueiredo]

Binary package hint: nautilus-share

Steps to reproduce
1- Create a usershare with nautilus (say, ~/Public)
2- From another computer, send a file to this share

The file will have ownership to user "nobody" and group "nogroup", instead of the userś ownership and starting group. This makes it inconvenient to modify these files, especially since there's no easy way to change ownership of files and folders (one has to know about the nautilus-gksu package, which is not installed by default).

[Chris Coulson (chrisccoulson)]

I don't think this is a nautilus-share problem as it is only responsible for initially creating the share, so I've reassigned this to Samba. Could you please provide the following additional information:

1. Please attach your /etc/samba/smb.conf to this bug report.
2. Please run "tar -czf usershares.tar.gz /var/lib/samba/usershares" and attach the resulting file "usershares.tar.gz" to this bug report.

Thanks

[Felipe Figueiredo (philsf)]

Thanks for the quick answer. Here are the asked files.

[Felipe Figueiredo (philsf)]

Since I only have a "Public" usershare, I'll not tgz it, and attach it directly.

[arnau (arnaullv)]

I think this a big security issue!

Once you create a Public folder you cannot delete any of the contents created by guest users!
It is posible to fill up your drive with junk and not being able to delete it (easily of course).

[arnau (arnaullv)]

Under /var/lib/samba/usershares/public:

#VERSION 2
path=/home/arnau/Públic
comment=
usershare_acl=S-1-1-0:F
guest_ok=y

This is an example of the security dangerous share, I also attached tar.gz file

[Felipe Figueiredo (philsf)]

Em Ter, 2008-12-23 às 15:17 +0000, arnau escreveu:
> I think this a big security issue!
>
> Once you create a Public folder you cannot delete any of the contents created by guest users!
> It is posible to fill up your drive with junk and not being able to delete it (easily of course).
>
How exactly is it a security issue? Certainly not by filling up space by
a non-user account, since this is means no threat to the user.

The shares you've shown, are standard open shares. Please give more
details on what you mean.

FF

[arnau (arnaullv)]

Yes, this is the problem. Once somebody places any file into this folder,
this file has owner: nobody group: nobody.
So this means that I cannot delete (because I don't own them) the files
created on my share folder! (I need to go to command line chown, etc...) If
some user wants to do it they can fill up my computer's harddrive with junk
I cannot delete!

2008/12/23 Felipe Figueiredo <email address hidden>

> Em Ter, 2008-12-23 às 15:17 +0000, arnau escreveu:
> > I think this a big security issue!
> >
> > Once you create a Public folder you cannot delete any of the contents
> created by guest users!
> > It is posible to fill up your drive with junk and not being able to
> delete it (easily of course).
> >
> How exactly is it a security issue? Certainly not by filling up space by
> a non-user account, since this is means no threat to the user.
>
> The shares you've shown, are standard open shares. Please give more
> details on what you mean.
>
> FF
>
> --
> files incoming through nautilus-share should be created with user
> ownership, instead of "nobody"
> https://bugs.launchpad.net/bugs/268663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Arnau Llovet Vidal
<email address hidden>

[arnau (arnaullv)]

I reinstalled my whole system (ubuntu 8.10), and now I can delete the files with no owner on the public folder.
But if I try doing Cut and paste somewhere else on a file left in the public folder (has owner: nobody group: nobody) it still gives the error access denied.

[Kai Jauch (kaijauch)]

Still an issue in Ubuntu 9.04.
If you create a share writable by everyone through nautilus, the files uploaded by anonymous users belong to nobody:nogroup with 0744, thus preventing the user from editing the files without manually fixing the ownership via sudo.

| $ ls -l ~/test
| -rwxr--r-- 1 nobody nogroup 419055 2009-03-20 14:31 testfile

nautilus-share:
  Installed: 0.7.2-0ubuntu7
  Candidate: 0.7.2-0ubuntu7
  Version table:
 *** 0.7.2-0ubuntu7 0
        500 http://de.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

Attaching /var/lib/samba/usershares/test.

[Chow Loong Jin (hyperair)]

nautilus-share adds user shares by running a command "net usershare add ____". Currently, there is no real way to add a user share that has the "inherit owner = yes" option set. Hence, I'm marking samba as affected as well.

[Chow Loong Jin (hyperair)]

Perhaps it would be a good idea to make the default smb.conf contain that flag within [global].

[Chow Loong Jin (hyperair)]

On Sunday 30,August,2009 03:57 AM, arnau wrote:
> ** Also affects: hundredpapercuts
> Importance: Undecided
> Status: New
>
It's not a trivial change. Samba needs to be patched, and then nautilus-share.
Hence, not a papercut.

  affects hundredpapercuts
  status invalid

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[arnau (arnaullv)]

I also think that it is a very good idea to add "inherit owner = yes" smb.conf under [global]

Otherwise end user will never understand what's going on! I hope it can still be done for 9.10

[Bartong (barton-guy)]

This is still an issue in Karmic.

I tried using the 'inherit owner = yes' parameter both in /var/lib/samba/usershares/<sharename> and in /etc/samba/smb.conf, but this resulted in other clients not being able to write to the server, so it is not a fix

The only fix I have found is to set 'create mask = 0777' and 'directory mask = 0777' in the [global] section of /etc/samba/smb.conf which means the owner and group is still nobody:nobody, but full read/write permissions are granted to any user including guests on any file or directory created in the share.

Setting these two parameters in /var/lib/samba/usershares/<sharename> does not currently seem to work.

[Chow Loong Jin (hyperair)]

On Sunday 01,November,2009 04:45 PM, Bartong wrote:
> This is still an issue in Karmic.
Yes yes can you see the status? One says "new", and the other says "confirmed".
We don't need more confirmations, thank you very much. If you have a good idea
on how to fix this issue, then post. Otherwise please don't. If you're looking
to subscribe, click on the link over there that says "Does this bug affect you?"

> I tried using the 'inherit owner = yes' parameter both in
> /var/lib/samba/usershares/<sharename> and in /etc/samba/smb.conf, but
> this resulted in other clients not being able to write to the server, so
> it is not a fix
>
> The only fix I have found is to set 'create mask = 0777' and 'directory
> mask = 0777' in the [global] section of /etc/samba/smb.conf which means
> the owner and group is still nobody:nobody, but full read/write
> permissions are granted to any user including guests on any file or
> directory created in the share.
Both "inherit owner = yes" and "create mask = 0777" have to be used in
conjunction with each other. "inherit owner = yes" will make the files be owned
by you, i.e. the owner of the share. "create mask = 0777" will ensure that
others can still write into the created files. Using "inherit owner = yes"
without a proper create mask will ensure that files that have been dropped into
a public share cannot be touched by others later on.
>
> Setting these two parameters in /var/lib/samba/usershares/<sharename>
> does not currently seem to work.
I've spoken to the samba people about this, and they're not entertaining the
idea of having inherit owner as an additional option to usershares. This pretty
much means that unless anyone can come up with a solution for making this work
automatically within nautilus-share code, this bug is not going to go anywhere.

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

[Chuck Short (zulcss)]

Im marking this as wont fi as per upstream.

Regards
chuck

[Felipe Figueiredo (philsf)]

Chuck, did you see the upstream comment? I don't know exactly what the option suggested means, but it seems like a matter of configuration. Maybe if this is made in the default smb.conf it would make this bug trivially fixable.

[Kai Blin (kai.blin)]

See http://lists.samba.org/archive/samba/2006-September/124961.html for an explanation of the option

[NeS (ernest-figueras)]

Thanks Bartong for your help!
with these two lines in smb.conf I am finally able (fingers crossed) to get rid of this nagging problem. I wish this was the default in ubuntu, not the other way around.
I think this *should* be fixed, linux is complicated enough without having to resort to this kind of kludges, imagine a newbie if he/she finds him/herself in this situation, they would give up almost instantly.
IMHO we should really focus on the usability of the system for beginners

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[rduke15 (rduke15)]

The solution for this problem ( copied from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678834#20 ):

The filesystem permissions of a fully publicly shared directory (i.e. ~/Public) has to be drwxrwsrwx.

   chmod a+rwx ~/public
   chmod g+s ~/public

And /etc/samba/smb.conf has to contain the line

   inherit permissions = yes

in the [global] section.