SUMMARY Using dolphin to copy files into a directory which has the group setuid bit set, will ignore this bit. That means the files copied will have the primary group set of the user performing the copy instead of the group of the parent directory. STEPS TO REPRODUCE 1. Create a directory "test" with following permissions: rwx rws --- myuser commongroup That is the directory is accessible and modifyable by myuser and all members of commongroup. The "s" indicates the group setuid bit is set and should enforce that each file copied into this directory should get "commongroup" as group ownership The exact set of commands to set this up are - mkdir test - chmod u+rwx,g+rwxs,o= test - chgrp commongroup test Note commongroup must be an existing group which is not the primary group of user myuser for this test. 2. Start dolphin and copy any file into this test directory 3. Check file ownership via the command line: - ls -l test OBSERVED RESULT The group of the copied file is myuser's primary group EXPECTED RESULT The group of the copied file is "commongroup" as per the setuid bit behavior. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.12.6 KDE Frameworks Version: 5.48.0 Qt Version: 5.9.6 ADDITIONAL INFORMATION A copy on the command line using "cp" does the right thing. This erratic behavior makes it unnecessarily hard to share files in a networked multi-user environment. In the past a similar bug was reported against gwenview: bug 149148. As that bug is closed and I'm seeing this in dolphin, I chose to create a new bug.
It's faster to just show the shell output: [~/test-setgid]>$ mkdir ~/test-setgid [~/test-setgid]>$ cd ~/test-setgid/ [~/test-setgid]>$ sudo chown ahmad:users ./ [~/test-setgid]>$ sudo chmod g+s ./ [~/test-setgid]>$ ls -ld drwxr-sr-x 2 ahmad users 4096 Sep 24 00:14 . Creating a new file and dir from the cli: [~/test-setgid]>$ touch file [~/test-setgid]>$ mkdir dir [~/test-setgid]>$ ls -l total 4 drwxr-sr-x 2 ahmad users 4096 Sep 24 00:15 dir -rw-r--r-- 1 ahmad users 0 Sep 24 00:15 file [~/test-setgid]>$ ls -l ~/copied-file -rw-r--r-- 1 ahmad ahmad 10 Sep 24 00:16 /home/ahmad/copied-file [~/test-setgid]>$ cp ~/copied-file . [~/test-setgid]>$ ls -l total 8 drwxr-sr-x 2 ahmad users 4096 Sep 24 00:15 dir -rw-r--r-- 1 ahmad users 10 Sep 24 00:16 copied-file -rw-r--r-- 1 ahmad users 0 Sep 24 00:15 file [~/test-setgid]>$ ls -ld ~/copied-dir drwxr-xr-x 2 ahmad ahmad 4096 Sep 24 00:16 /home/ahmad/copied-dir [~/test-setgid]>$ cp -r ~/copied-dir . [~/test-setgid]>$ ls -l total 12 drwxr-sr-x 2 ahmad users 4096 Sep 24 00:16 copied-dir drwxr-sr-x 2 ahmad users 4096 Sep 24 00:15 dir -rw-r--r-- 1 ahmad users 10 Sep 24 00:16 copied-file -rw-r--r-- 1 ahmad users 0 Sep 24 00:15 file Now with dolphin: [~/test-setgid]>$ ls -ld ~/copied-file-with-dolphin ~/copied-dir-from-dolphin/ drwxr-xr-x 2 ahmad ahmad 4096 Sep 24 00:27 /home/ahmad/copied-dir-from-dolphin/ -rw-r--r-- 1 ahmad ahmad 6 Sep 24 00:26 /home/ahmad/copied-file-with-dolphin Copied the the two above items using dolphin, and the result: [~/test-setgid]>$ ls -l copied-file-with-dolphin -rw-r--r-- 1 ahmad ahmad 6 Sep 24 00:26 copied-file-with-dolphin [~/test-setgid]>$ ls -ld copied-dir-from-dolphin/ drwxr-sr-x 2 ahmad users 4096 Sep 24 00:27 copied-dir-from-dolphin/ So it looks like it's the same behaviour as using cp from the cli. Can you still reproduce this issue?
(In reply to Ahmad Samir from comment #1) > Copied the the two above items using dolphin, and the result: > [~/test-setgid]>$ ls -l copied-file-with-dolphin > -rw-r--r-- 1 ahmad ahmad 6 Sep 24 00:26 copied-file-with-dolphin > [~/test-setgid]>$ ls -ld copied-dir-from-dolphin/ > drwxr-sr-x 2 ahmad users 4096 Sep 24 00:27 copied-dir-from-dolphin/ > > So it looks like it's the same behaviour as using cp from the cli. > > Can you still reproduce this issue? The file "copied-file-with-dolphin" in your output above shows exactly the issue I'm pointing out: its primary group is still ahmad instead of users. So it seems you are equally able to reproduce this issue... And I have just tested, it still happens for me as well. Interestingly it seems to go wrong for files only. The group id is set correctly on directories.
I'll add that since I reported this I have upgraded to frameworks-kio-5.59.0 (which is current on Fedora 30).
It's the same with copied-file which was copied with cp. So it isn't specific to KIO/dolphin. From the chomd man page: <quote> SETUID AND SETGID BITS chmod clears the set-group-ID bit of a regular file if the file's group ID does not match the user's effective group ID or one of the user's supplementary group IDs, unless the user has appropriate privileges. Additional restrictions may cause the set-user-ID and set-group-ID bits of MODE or RFILE to be ignored. This behavior depends on the policy and functionality of the underlying chmod system call. When in doubt, check the underlying system behavior. </quote> I don't fully understand that, but it may explain the issue.
I don't agree it's the same. Your file generated using cp is this: -rw-r--r-- 1 ahmad users 10 Sep 24 00:16 copied-file Your file generated using copy in dolphin is this: -rw-r--r-- 1 ahmad ahmad 6 Sep 24 00:26 copied-file-with-dolphin Note the difference in group id! copied-file is owned by group "users", where copied-file-with-dolphin is owned by group "ahmad". Considering the group setuid bit was set on the containing directory, the command line copy's behaviour is the proper one. Dolphin's copy ignores this group setuid bit. However as we have both established, it only does so for files, not for directories.
Hmm, I'll test again, it seems I either missed it when I tested, or I copy pasted wrongly when posting here...
You're correct, I must have gone blind when I tested the first time around...