why can I write to a file I don't have permission to??

[David.Knight at clubcorp.com]

Nice Web Site Bill.






David.Knight at clubcorp.com
Sent by: redhat-list-bounces at redhat.com
04/14/2005 09:55 PM
Please respond to General Red Hat Linux discussion list

 
        To:     General Red Hat Linux discussion list <redhat-list at redhat.com>
        cc:     General Red Hat Linux discussion list <redhat-list at redhat.com>, 
redhat-list-bounces at redhat.com
        Subject:        RE: Re: why can I write to a file I don't have permission to??


On April 14, 2005 02:56 pm, David.Knight at clubcorp.com 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 at mercuryspeed.com
http://webhome.idirect.com/~kbmed

-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list