I wanted to share some files between two users. So I created a new group let's say both and added there users to the group.
Then I created a directory (shared) which was changed to the group both and with the setgid bit set (chmod 2770 shared). I thought that any file put in this directory will belong to the original user and group both. In fact this is only true for the newly created files (by touch for example) but if I use cp or mv or drag and drop under KDE) the original group is kept.

The aim was to be able to have
father
+- Documents
+- family -> family/documents
and
mother
+- Documents
+- family -> family/documents

Then father and mother could read any file placed in ?/family. Idealy father should only be able to delete his own files not the the mother's ones but that would be «heaven» I do know linux is heaven but didn't got the keys up to now...

Thanks for reading my bad English (and for any help).

French Guy

setgid is irrelevant to your problem. It doesn't modify the group ownership of files, but merely causes processes that run executable files to run under the group id that owns the file (the group equivalent of suid).

New files (including copies from elsewhere) usually have the group ownership of the user's default (login) group, regardless of the group ownership of the directory. However they can always be given the ownership of any group that user belongs to, using the chgrp command. Unlike chown, this command can be used by any user.

In other words, it's up to father and mother to make public the files that they want to share with each other by assigning them to the "family" group. But you can ensure that they can't delete each other's files. That's what the sticky bit is for.

1 members found this post helpful.

The mv command will always behave that way. Moving a file within the same filesystem is just a rename operation (create a new hard link, then remove the old one) and does not otherwise touch the file's inode. When moving a file to a different filesystem, the mv command attempts to emulate that simple rename as far as possible and tries to preserve the original ownership and permissions. The cp command should not be doing that unless you have used one of the options to preserve ownership. You might check whether your cp is actually an alias that includes one of those options. Drag and drop could be doing just about anything, and might even be configurable.

The setgid bit on a directory has a different meaning. With the usual default mount options it causes newly created files to inherit the GID of the directory. Newly created directories also inherit the setgid mode bit.

3 members found this post helpful.

You learn something every day!

1 members found this post helpful.

Your post is about the setgid but. The intended use and the answers are correct. However, in your thread title you use sticky bit. Although often confused, your question is not about the sticky bit, it is about the setgid bit.

The sticky bit prevents files removed by someone else but the owner. The sticky bit is usually set on the /tmp directory. Everyone can write into /tmp, but everyone can also only delete their own files.
jlinkels

1 members found this post helpful.

Historically the t-bit on files had another meaning:
the files were kept longer in memory.
Therefore the name "sticky".
Modern concepts like paging made this obsolete, and a t-bit on files does nothing.
But the t-bit on directories still has the meaning as was described in the previous post.
I usually say t-bit and s-bit and g+s bit.
In this thread: g+s bit.

1 members found this post helpful.

Thanks a lot for these explanations. I'didn't dig enough in the work mv and cp did. I think I owe you a much better understanding of the situation and will try to adapt to it : In fact I'm trying to setup a machine for a beginners family (old sony vio with 2G RAM) to access internet and visualize photos) I think I'll create only one user for them both and that's all.
Again thanks to everybody who took the time to explain.
Proud to be a member of such a community.
Sincerely
Jean-Pierre

Reading your original post again, you say that mom and dad should be able to read each other's files. That is still possible if you use a shared directory. If you set the umask to 022 (as it usually is set by default) file are created rw-r--r--. So they can read each other's file but not edit or delete them.


jlinkels

I think psychologically it would be a good idea to give each user a separate identity because the whole idea of file ownership and permissions is so important in Linux. The easiest way for them to grasp this is for each to have a username, a password, and a private directory for storing files that are not to be looked at by others. Then you can also give them a common directory where they can put files for sharing, with the sticky bit set so that they can't delete each other's files. And then outside that will be the directories and files owned by root. The fact that these files belong to the system and not to either of them will then be much easier to grasp.