On April 14, 2005 02:56 pm, David.Knight@xxxxxxxxxxxx wrote: > RedHat List, > I was working on a script the other day and ran into > an anomaly with the file permission's on files. I have checked > this on several ES servers and all produce the same results. Makes sense to me, as a weird behaviour of vi. > Say a file has the following perms: 644 and it is owner and > group are root:root. as long as a user has write permission's > to the directory it is in they can write to it. Not quite; they can delete it and then create a new one. > not only that > the UID:GID change to that user. Not quite; the new one correctly has the user as owner, since the user created it. (Interesting; it gets the same inode) > I am running ext3 file > systems with kernel 2.4.21-20.ELsmp. So my question is > > 1) why is this allowed? Standard Unix file permissions > 2) can I change this? Don't override vi's decision when it tells you that you are overriding a readonly file. > > # pwd > /home/test_dir > # rm test.fil > # pwd > /home/test_dir > # ls -ld . > drwxr-xr-x 2 user7 root 4096 Apr 14 16:56 . > # id > uid=0(root) gid=0(root) > groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel >) # echo "test from root" > test.fil > # ls -l test.fil > -rw-r--r-- 1 root root 15 Apr 14 16:57 > test.fil # su - user7 So I presume /home/test_dir is user7's home directory > $vi test.fil And presumably vi told you it was a readonly file. > $ ls -l test.fil > -rw-r--r-- 1 user7 user7 31 Apr 14 16:57 test.fil > $ cat test.fil > test from root > test from uset7 > > However it doesn't let you echo "test from user7" > > ./test.fil. it responds correctly...... because that would truly be trying to modify the file rather than replace it. > Any thoughts on this would be great. > -David Knight -- Bill Medland mailto:billmedland@xxxxxxxxxxxxxxxx http://webhome.idirect.com/~kbmed -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
