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. >>> File permission's are not controlled by a visual editor. It is of the filesystems design. > 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. >>> So the point stays the same! Why can a user remove a file that they don't have permission to??? >>> If file permission's do not matter then why have them??? why don't we let directories control >>> all the file permission's??? > 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. >>> Sorry but you obviously didn't test before you responded to this... (Interesting; it gets the same inode) >>> GETS the same inode??? it never changed! > > 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 >>> I have tested this on AIX/Tru64/Solaris and my RedHat servers are the only ones that have this odd behavor. >>> This is not a UNIX standard behavor! If there are reall UNIX Engineers on this list they will chime in. > 2) can I change this? Don't override vi's decision when it tells you that you are overriding a readonly file. >>> O even better we can just let vi deside all the security of our files. Now that's a real enterprise solution. >>> Your responce to this is as of a standard Microsoft person. Hell why don't we have unix tell us when it's not >>> right to remove a file or down an HBA or ask us if we are sure if we want to kill a process like Microsoft will? > > # 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 >>> No I changed the user name and home dir to be discreet about my box. Mayby you need >>> to go read some script kitty list before you make comments on my posting. > $vi test.fil And presumably vi told you it was a readonly file. >>> Not when I said !... Is a ! all some one hast to do to overwrits a files permissions on RedHat/ext3??? > $ 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. >>What ever... You really need to do someresearch or read a book before responding! > Any thoughts on this would be great. > -David Knight >>> Sorry folks, >>> New to this list didnt know what kind it was. I was really hoping for a better responce then that. Any one out there a real Unix >>> guy? When I ran accross this myself and 3 other Unix engineers though it was a bug. Our security manager even asked me to send >>> an E-Mail to our local RedHat sales Engineer to find a fix before we went live. my manager asked if this was true with GFS. I >>> would love some feed back from RedHat on this. >>> -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
