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
