dnd to a directory owned by an another user should default to copy (fix dnd to setgid shared directory by example)

priority is for the developers to set...

Thanks for your bug. What version of Ubuntu do you use? Is that the same as http://bugzilla.gnome.org/show_bug.cgi?id=104052 upstream? Do you have some simple step to describe to get the issue?

This appears to be the same bug as described above, I met Jeff Waugh at linuxworld confau and demo'd this to him and he said that he would get this fixed in the dot release before Dapper Drake comes out.. I have sent him an email to remind him the version is 2.14.0 so 2.14.x should have this fixed hopefully.

Ccing Jeff, do you have any pointer upstream or is that something we should work with upstream to get fixed?

Only know of
http://bugzilla.gnome.org/show_bug.cgi?id=104052

which mentions a fix in cvs for a prior nautilus dated 25th or Jan 2005

Apart from that there is no other help that I know I can give at this stage

Is anything happening with this? We need a fix ASAP, as it is breaking 3 of our sites. and we want to move to Dapper Drake.

Kind regards,

Matt
0421 616 733

Was that working with Ubuntu 5.10 and is broken now? Could you describe some simple actions to get the issue so we can work on it?

I went ahead and linked this to http://bugzilla.gnome.org/show_bug.cgi?id=104052; it really does look like the same bug. Feel free to beat me with a fish if I'm wrong.

ok exact process to reproduce

1. groupadd sharedtest // create's the "sharedtest" group

1. cat /etc/group |grep sharedtest // verifies it's been added ie output is >> sharedtest:x:552:

3. mkdir /home/sharedtest;chown root.sharedtest /home/sharedtest; ls -lad /home/sharedtest

>> output should look like
drwxr-xr-x 2 root sharedtest 4096 Apr 8 15:43 /home/sharedtest

4. chmod g+s /home/sharedtest; ls -lad /home/sharedtest
drwxr-sr-x 2 root sharedtest 4096 Apr 8 15:43 /home/sharedtest

5. adduser testuser

6. add testuser to group sharedtest

7. verify testuser is a member of sharedtest by doing a
su testuser -
then typing groups

8. touch /home/testuser/testfile ;ls -la /home/testuser/testfile

9. cp /home/testuser/testfile /home/sharedtest/; ls -la testfile

permissions should be testuser sharedtest

then do the same as above with testfile2 ... this time "cp -a /testuser/testfile2 /home/sharedtest/

permissions should be testuser testuser

login using gdm to gnome as user testuser

now use Nautilus to drag a file called testfile3 from the home directory of testuser to /home/shared

The result,,, the same as a cp -a ... a stands for archive and is for backing up. .It is not the desirable default behaviour.

Tested with Ubuntu Breezy 5.10 fully up to date using apt-get update and same behaviour as is being experienced in Dapper Drake Flight 6

Using nautilus to copy a file the default behaviour is archive, which means that files copied this way aren't viewable by colleagues who are members of the same group.. ie someone in the marketing department who wants his colleage to view his openoffice doc.

Based on your comments on IRC, is it correct to assume that this DOESN'T occur when copying files, but rather only when moving them?

If so, this is also how command line tools work (mv just essentially renames/reparents the file, but keeps permissions identical), and it's also how other operating systems work (no, really, try on WinNT with NTFS, copy will inherit permissions from the destination, move won't)

I'm not sure how this is a bug, though perhaps a wishlist to have an option in Nautilus to override the default "move" behaviour.

Adam,

It was my mistake in original testing.

I have tested this with my work environment @HP and with windows to
windowsshare the files are made available to my groups.

The problem is, that linux lends itself to being an internet appliance.
See "edubuntu" and in this situation where the disks are on the same box
as the end users, you want a local file location.

So the option to have moves check for setgid is a good one. At this
stage I have a kludge where every minute permissions are fixed from
cron. I have 3 sites like this, and I know of another site where a
friend has done a similair thing for his users.

So it is probably a bug if comparing to win32 behaviour, it is not a bug
if comparing to the default behavour of the linux mv command.

Any comments on this?

Regards,

Matt

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
Adam Conrad
Sent: Saturday, 8 April 2006 7:42 PM
To: Wright, Matthew
Subject: [Bug 36647] Re: setgid not respected when copying into a
directory

Based on your comments on IRC, is it correct to assume that this DOESN'T
occur when copying files, but rather only when moving them?

If so, this is also how command line tools work (mv just essentially
renames/reparents the file, but keeps permissions identical), and it's
also how other operating systems work (no, really, try on WinNT with
NTFS, copy will inherit permissions from the destination, move won't)

I'm not sure how this is a bug, though perhaps a wishlist to have an
option in Nautilus to override the default "move" behaviour.

--
setgid not respected when copying into a directory
https://launchpad.net/malone/bugs/36647

After discussion on IRC, that is the issue with that:
- nautilus does move on dnd by default (if you use the same partition)
- move doesn't change the owner and permissions of what is moved

Possibles changes for it:
- doing copy instead of move by default, but that's probably not what users expect
- making move respecting the setgid, but that's not coherent with the command line and breaks other usecases likely
- setting an option to change the default behaviour, but copy by default is not optimal
- having a way to flag those directories as special which change the dnd behaviour to them
- making the dnd doing copy by default is the destination is owned by an another user

Changing the dnd to copy when the directory is owned by an another user is probably the best option for that

I've forwarded that upstream: http://bugzilla.gnome.org/show_bug.cgi?id=339154

This upload fixes the issue:

 nautilus (2.14.1-0ubuntu5) dapper; urgency=low
 .
   * debian/patches/90_from_cvs_sort_volumes_list.patch:
     - patch from CVS, fix the volumes sorting
   * debian/patches/91_from_cvs_width_of_text_selection.patch:
     - patch from CVS, fix the width of the text selection for the text below
       icons mode
   * debian/patches/92_from_cvs_fix_sftp_ftp_permissions_display.patch:
     - patch from CVS, fix permission displaying on sftp and ftp
       (Ubuntu: #33211)
   * debian/patches/93_upstream_nautilus-dnd-user-owned.patch:
     - patch from the upstream mailing list, make dnd default to copy instead
       of move when the destination is owned by an another use, fix dnd to
       a shared setgid directory since the copy respects the setgid permission
       (Ubuntu: #36647)

I have just tested with Flight 7 and when I drag and drop to a g+s directory it now defaults as a copy which is a great solution

However

If I do a cut and paste.... the file goes from
/home/me/touchedfile me.me **Cut**

*paste*
ls /shared/touchedfile me.me

when it should ideally be me.shared
as /shared is chmod g+s

Can this be fixed please, and I really appreciate the work done that has made the environment a hell of a lot easier for end users.

Regards,

Mat

No, that's how "mv" works on unix, permissions are preserved

However, what would be the purpose of moving a file you own to a shared directory setgid group bit. and keeping the ownership for yourself?

the code is coherent, nautilus has no notion of "shared directory setgid group bit" and have special case would be confusing. Moving does preserve the permissions, that's the way it works under linux