why doesn't the home directory have the sticky bit set?

[rm-rf]

Let's say that a group has 3 members (Joe, Sam and Sue), all working on a project together.
Perhaps they are working on 3 different aspects of it. You could set the sticky bits on the files for each of them so that they can't be modified by the other members of the group, but can be read by them.
Joe wants to let Sam and Sue see how far he has gotten on his part of the project, so they take a look.
He can feel safe doing so because there is no chance of accidental modification or deletion of the document.

Just one example.

Yes however the problem is that it is far more likely that you would want the sticky bit set by default on directories where others are allowed to write to them, this way if Joe wants them to be able to modify it, he can just set the file permissions on the file to allow it. By default the file permissions and ownerships are ignored when they are in directories which others can write to. This brings up the question: why even have them if you are just going to ignore them?

[jayd512]

Sorry... I should have explained what I mean a little better
Those 3 members would have a folder created that they all have permissions to access, read to and write to.
But individual files in that folder can be set with a sticky bit.

So, all files and documents for the project are in the same folder, making collaboration easier.
So Sam can read Sue's file, but only Sue can modify or delete it.

I see where the confusion is... I didn't get the point of it either, at first.

[kohog]

I see where the confusion is... I didn't get the point of it either, at first.

You still don't get the point...
The sticky bit has a completely different effect on files. From Wikipedia:

The sticky bit was introduced in the Fifth Edition of Unix in 1974 for use with pure executable files. When set, it instructed the operating system to retain the text segment of the program in swap space after the process exited. This speeds up subsequent executions by allowing the kernel to make a single operation of moving the program from swap to real memory.

This usage of the sticky bit is now obsolete and the sticky bit on executable files has no effect at all

What we are talking about is its effect on directories. The sticky bit makes directories "append-only." This means that you cannot delete files owned by others.

You could set the sticky bits on the files for each of them so that they can't be modified by the other members of the group, but can be read by them.

This is where you are wrong. To achieve this, you should set +r-w on the files. However, this requires the sticky bit on the directory, because without it, any user with write access to the directory could delete the file and replace it with their own modified copy, even when the owner has write-protected the file by setting the -w permission.
In other words: without the sticky bit on the directory, write-protecting your files is meaningless.

It is this I cannot see as desirable in any situation. Hence my question: why isn't the sticky bit always set?

[jayd512]

I never mentioned executables. I was talking about read-write access.
But from the same page you linked to...

This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files.

By the way...

without the sticky bit on the directory, write-protecting your files is meaningless.

Not true. Look at your own home directory. No sticky bit. But if another user logs in to the computer, they have no read-write access to your files.

Honestly, though, if you feel that sticky-bits should be applied to everything, go ahead and set them. If you feel that it will cause no harm, set them.

[kohog]

I think you should test things before you post on the forum. You would discover that you are wrong about everything you have written here...

I never mentioned executables. I was talking about read-write access.

You were talking about setting the sticky bit on files. This has no effect on read-write access (or anything else). Read the Wikipedia article. It says that the sticky bit on files is simply ignored in Linux. Read-write access is not affected in any OS mentioned in the article.
Try it if you don't believe me.

This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files.

That's exactly what I said...

I
Not true. Look at your own home directory. No sticky bit. But if another user logs in to the computer, they have no read-write access to your files.

That's because only the owner has the +w permission, ie it is not publicly writable, like /tmp. If you give others write permission (go+w), they will be able to delete files they don't own, even write-protected files. This is what the sticky bit fixes.

jof@ocales:~$ cd /tmp/                                                                                                              
jof@ocales:/tmp$ mkdir shared
jof@ocales:/tmp$ chmod a+rw shared/
jof@ocales:/tmp$ cd shared/
jof@ocales:/tmp/shared$ echo You are not allowed to modify this file>mywriteprotectedfile 
jof@ocales:/tmp/shared$ chmod a-w mywriteprotectedfile 
jof@ocales:/tmp/shared$ su kohog
Password: 
kohog@ocales:/tmp/shared$ ls -l
total 4
-r--r--r-- 1 jof users 40 2011-07-30 22:47 mywriteprotectedfile
kohog@ocales:/tmp/shared$ cat mywriteprotectedfile 
You are not allowed to modify this file
kohog@ocales:/tmp/shared$ echo But I want to! >>mywriteprotectedfile 
bash: mywriteprotectedfile: Permission denied
kohog@ocales:/tmp/shared$ cp mywriteprotectedfile temp
kohog@ocales:/tmp/shared$ chmod a+w temp 
kohog@ocales:/tmp/shared$ echo But I want to AND YOU CAN\'T STOP ME >>temp
kohog@ocales:/tmp/shared$ rm mywriteprotectedfile 
rm: remove write-protected regular file `mywriteprotectedfile'? y
kohog@ocales:/tmp/shared$ mv temp mywriteprotectedfile
kohog@ocales:/tmp/shared$ chmod a-w mywriteprotectedfile 
kohog@ocales:/tmp/shared$ exit
exit
jof@ocales:/tmp/shared$ ls -l
totalt 4
-r--r--r-- 1 kohog users 76 2011-07-30 22:48 mywriteprotectedfile
jof@ocales:/tmp/shared$ cat mywriteprotectedfile 
You are not allowed to modify this file
But I want to AND YOU CAN'T STOP ME

It what situation could this behavior possibly be desirable?

[jayd512]

You just gave an example of changing files owned by another user in the /tmp directory.
Okay. We know that's possible.
If, however, I decide to store something in the /tmp directory, than I might not care very much about who deletes/modifies it.
And we know that's what sticky bits are there to protect against. Great.

Which is exactly what I was trying to get across in my earlier posts.


And on that note, I shall now agree that we disagree.

[Jonathan183]

If I understand how it works ... if you have a group of users who you trust to read & write data to a shared folder (eg a project team), read only gives a prompt before deleting but does not stop the file from being deleted. File creator is not special in the group. That sort of situation could occur quite frequently, and if you had several users join & leave the group it would not be great to have to change file ownership.

[kohog]

You just gave an example of changing files owned by another user in the /tmp directory.
Okay. We know that's possible.
If, however, I decide to store something in the /tmp directory, than I might not care very much about who deletes/modifies it.

The result would be the same in any directory, because the /tmp directory is not treated differently than any other. You are wrong again!
I put the files there simply because I don't want junk files anywhere else.

And we know that's what sticky bits are there to protect against. Great.
.

Yes. And for the third time: why isn't it the default behavior for directories? In what situation do you want others to be able to delete/change your files, even when you have write-protected them?

Which is exactly what I was trying to get across in my earlier posts.

No, you were saying that setting the sticky bit on files protects them. This is simply wrong and you have only demonstrated your own ignorance.


What I asked for, was an example of a situation where you do NOT want the sticky bit on a directory. I know there are situations where it doesn't matter (like your home directory) but I want an example where the sticky bit has an undesired effect.

[kohog]

if you had several users join & leave the group it would not be great to have to change file ownership.

OK, it would be annoying that you couldn't delete the files if someone leaves the group. I'm satisfied with that example.
So, both situations are bad:
With the sticky bit set, you cannot delete files even if you have write permission to both the file and the directory.
Without the sticky bit, others can delete and modify (as my example showed) your files, even if you write-protect them.

The fundamental problem is that it is possible to delete write-protected files without making them writable first.