why can I write to a file I don't have permission to??
David.Knight at clubcorp.com
David.Knight at clubcorp.com
Fri Apr 15 02:55:37 UTC 2005
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
More information about the redhat-list
mailing list