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

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

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

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

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).

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

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

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>

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.

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.

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.

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

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

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

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.

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

Im marking this as wont fi as per upstream.

Regards
chuck

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.

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

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

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

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.