perlperl
asked on
POSIX file checking semantics
I am trying to understand why does POSIX behaves in this wierd manner.
1) I created two users "user_a" and "user_b" and both belongs to same "group"
2) sudo "user_a".
a) Created a Dir /home/users/dir_1. The owner is "user_a" and permission is 777.
b) Created a file /home/user/dir_1/file.txt with permission 644 and owner is "user_a"
3) sudo "user_b"
a) cd /home/user/dir_1
b) echo "test" >> file.txt fails with "Permission Denied" as expected.
c) vi file.txt opens the file warns its a "Read Only" mode. Then I write at the end of file and close vi with !wq. BOOM, the write succeeded and I verified using cat that the write got commited to the disk.
Why on earth Unix allows to write using 3.c but fails during 3.b.
3.c should have failed with "permission denied" but it does not
1) I created two users "user_a" and "user_b" and both belongs to same "group"
2) sudo "user_a".
a) Created a Dir /home/users/dir_1. The owner is "user_a" and permission is 777.
b) Created a file /home/user/dir_1/file.txt with permission 644 and owner is "user_a"
3) sudo "user_b"
a) cd /home/user/dir_1
b) echo "test" >> file.txt fails with "Permission Denied" as expected.
c) vi file.txt opens the file warns its a "Read Only" mode. Then I write at the end of file and close vi with !wq. BOOM, the write succeeded and I verified using cat that the write got commited to the disk.
Why on earth Unix allows to write using 3.c but fails during 3.b.
3.c should have failed with "permission denied" but it does not
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
"At the end of vi the filename is still same and contents are changed. so if the original user sees his file he will see an updated file which he never updated. "
from above ,this statement .
"also note that userA does not own the file anymore"
my observation: when I did the stat on the file name whose conents were in vi buffer ,
as stated .
it was owned by userb and not by user_a
so user _A can not append to that file .
reason : I searched through vi manual to find that , it was user_b who had opend the buffer ,for file ,theit was the user_b took the empty file ...and then created the emtpy buffer and populated it .....
may be the since user_B had started from fresh on buffer for file , he is the owner , not the user_a and so he is not able to append to it .
thanks,
s.deviprasad
from above ,this statement .
"also note that userA does not own the file anymore"
my observation: when I did the stat on the file name whose conents were in vi buffer ,
as stated .
it was owned by userb and not by user_a
so user _A can not append to that file .
reason : I searched through vi manual to find that , it was user_b who had opend the buffer ,for file ,theit was the user_b took the empty file ...and then created the emtpy buffer and populated it .....
may be the since user_B had started from fresh on buffer for file , he is the owner , not the user_a and so he is not able to append to it .
thanks,
s.deviprasad
ASKER
how can vi delete the file if it is not owned by the user. I mean why does the "rm" succeeded in your example even though file is owned by root
At the end of vi the filename is still same and contents are changed. so if the original user sees his file he will see an updated file which he never updated.