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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bill,

> I did; try "perhaps you didn't test" in future

Clearly the file is not removed. The research that I preformed 
clearly shows that the process recognizes that it is read only 
but then a chmod/chown is issued (System Call Trace BELOW). 
This may be ok with you bill but it is not something that I want
to happen on my servers. 

> When I was dry-running my answers before 
> responding to your post (Oh woops; I didn't test before I spoke, 
> did I?) I suddenly noted that you used su - rather than su; that 
> only made sense if the home dir was the same dir.  (I didn't 
> consider the possibility that what appeared to be a true dump of 
> the process was actually modified; that's the way people get 
> confused!)

A dry run? it that your testing? I listed an example of what I was 
talking about NOT my test results. It is standard practice for people
to change there IP address/users/hostname/etc when posting. what do 
you mean when you say:""I suddenly noted that you used su - rather 
than su; that only made sense if the home dir was the same dir."" 
The home dir is set in the /etc/passwd file and does not need to 
match the user name. I think you got confused because of your own 
lack of skills. O was that my 7th insult? 

I posted this in hopes to try to have real technical responses. I 
did not expect some one like your self would try to down what I was 
asking. You should really make sure you know what you are talking about 
before you post to any list. You could unintentionally lead some one
in the wrong direction and waste peoples time with your non since.
I'm not trying to insult anyone I know everyone is at a different level
in there skill sets. I'm better at some flavors then others but the
difference is I don't asked like I am better at something when I am not.
I will end this since I really don't have time to waste like this I will
Get a response from RedHat Engineering on this question and post a Summary
when I do. 
Regards,
David Knight

open("test", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EACCES 
(Permission denied)
lstat64("test", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
getuid32()                              = 501
unlink("test")                          = 0
open("test", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
write(3, "test\n", 5)                   = 5
close(3)                                = 0
chmod("test", 0644)                     = 0
write(1, " 1L, 5C written", 15)         = 15
stat64("/home/dknight/test", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0
unlink("test~")                         = 0
getcwd("/home/dknight", 1024)           = 14
open("/home/dknight/.viminfo", O_RDONLY|O_LARGEFILE) = 3
stat64("/home/dknight/.viminfo", {st_mode=S_IFREG|0600, st_size=648, ...}) 
= 0
getuid32()                              = 501
getuid32()                              = 501
stat64("/home/dknight/.viminfo.tmp", 0xbfffb840) = -1 ENOENT (No such file 
or directory)
open("/home/dknight/.viminfo.tmp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 
0666) = 4
chmod("/home/dknight/.viminfo.tmp", 0600) = 0
chown32("/home/dknight/.viminfo.tmp", 501, 501) = 0
fstat64(3, {st_mode=S_IFREG|0600, st_size=648, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0xb73dd000
read(3, "# This viminfo file was generate"..., 4096) = 648
fstat64(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0xb73dc000
read(3, "", 4096)                       = 0
write(4, "# This viminfo file was generate"..., 695) = 695
close(4)                                = 0



_________________________________________________________________
On April 14, 2005 08:05 pm, David.Knight@xxxxxxxxxxxx wrote:
> Nice Web Site Bill.

Thanks.  Actually it's been dead for years, since I changed ISP

*** High dudgeon ensues (off the mailing list) ***

> >>> Sorry but you obviously didn't test before you responded
> >>> to this...

I did; try "perhaps you didn't test" in future

> >>> This is not a UNIX standard behavor! If there are reall
> >>> UNIX Engineers
>
> on this list they will chime in.

Second insult!

>
> > 2) can I change this?
>
> Don't override vi's decision when it tells you that you are
> overriding a readonly file.

I aplogise; I guess that was a bit flippant

>>> 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?

Third insult

(I have used George IV (I think), Sinclair, CP/M, VMS, MS-DOS, 
SCO Unix, Windows and Linux.  I actually like the Unix file 
system)

> 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.

Fourth insult.  When I was dry-running my answers before 
responding to your post (Oh woops; I didn't test before I spoke, 
did I?) I suddenly noted that you used su - rather than su; that 
only made sense if the home dir was the same dir.  (I didn't 
consider the possibility that what appeared to be a true dump of 
the process was actually modified; that's the way people get 
confused!)

> >>What ever... You really need to do someresearch or read a
> >> book before
>
> responding!

Fifth insult

>
> > 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

Sixth insult.

>
> 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.

In case it wasn't clear, I took offence to your response.!

-- 
Bill Medland
mailto:billmedland@xxxxxxxxxxxxxxxx
http://webhome.idirect.com/~kbmed



___________________________________________________________________

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

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux