Ryan R. Frederick wrote:
| Mhoram wrote:
|
|>I am wondering if the following scenario (which I can produce on
|>RedHat 8 and RedHat 9 systems, but not on AIX or Solaris) is a bug or
|>is done by design.
|>
|>I create a directory called /test with permissions of 777. Then, as
|>user1, I create a file called testfile in that directory. The file
|>has permissions of 664, owner is user1, and group is user1. I then
|>log in as user2, change to the test directory, and edit the file using
|>vi. Vi correctly states that the file is being opened read-only.
|>While still in vi, I add a line to the file and try to save it using
|>:w – to which vi again states that the file is read-only. So far so
|>good. But if I save my changes using :w! - vi allows the change.
|>When I exit vi and do an ls, the file still has permissions of 664,
|>but is now owned by user2 with a group of user2.
|>
|>Is this how it should work? I thought that file permissions would
|>override the directory permissions in the above example when trying to
|>write to the file. And even if the file changes should be allowed to
|>be written, I was certainly surprised to see the owner and group
|>change.
|>
|>Thanks for any input.
|
|
| If you don't want people to be able to remove or write over other
| peoples files you need to set the sticky bit..
|
| chmod 1777 /test
| then user1 can create a file and user2 will not be able to write over
| that file.. or delete that file. Files which are readonly can still be
| deleted other wise...
|
| bob
|
you know, chmod does not contain much info about the sticky bit. Where
can I find some?