Attached is the output of ksymoops from an Oops when mounting from a broken
NFS server. I was experimenting with a new security policy for the NFS
server and didn't grant the daemons all the access they needed. Afterwards I
noticed that kernel had Oops'd on a mount command (I should have suspected
when the mount SEGV'd).
I can probably reproduce this if requested. It's 2.4.22 client and server.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
On Sat, 13 Sep 2003 19:38, Russell Coker wrote:
> Attached is the output of ksymoops from an Oops when mounting from a broken
> NFS server. I was experimenting with a new security policy for the NFS
> server and didn't grant the daemons all the access they needed. Afterwards
> I noticed that kernel had Oops'd on a mount command (I should have
> suspected when the mount SEGV'd).
>
> I can probably reproduce this if requested. It's 2.4.22 client and server.
This is embarassing. I attached the wrong file to the last message. Attached
is the correct one.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Without a tcpdump, there's no way to know why this dumped. In what way
was the NFS server broken, and exactly how do you expect the Linux NFS
client to protect you against it?
Cheers,
Trond
>>>>> " " == Trond Myklebust <[email protected]> writes:
> Without a tcpdump, there's no way to know why this dumped. In
> what way was the NFS server broken, and exactly how do you
> expect the Linux NFS client to protect you against it?
BTW: that Oops you posted looked very much like a memory corruption
problem. Were you running vanilla 2.4.22 on the client, or was it too
patched?
Cheers,
Trond
On Tue, 16 Sep 2003 01:38, Trond Myklebust wrote:
> Without a tcpdump, there's no way to know why this dumped. In what way
> was the NFS server broken, and exactly how do you expect the Linux NFS
> client to protect you against it?
The NFS server was unable to read the directories it was exporting, so it
would allow the mount command but then fail to do anything.
I expect the NFS client to behave sensibly in the face of all possible server
errors, including the possibility of a hostile NFS server.
> BTW: that Oops you posted looked very much like a memory corruption
> problem. Were you running vanilla 2.4.22 on the client, or was it too
> patched?
It was also patched. I will try and reproduce the error with an unpatched
kernel and a tcpdump running.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
>>>>> " " == Russell Coker <[email protected]> writes:
> I expect the NFS client to behave sensibly in the face of all
> possible server errors, including the possibility of a hostile
> NFS server.
No can do... There are 100s of scenarios where the server can screw
the client by giving it bogus information. You might possibly be able
to protect against a few of them, but at a heavy price in the form of
code bloat.
Neither NFSv2 nor NFSv3 are protocols that were designed to operate
safely in a hostile environment. They were designed for LANs where
servers and clients trust one another.
I agree that we shouldn't Oops though.
>> BTW: that Oops you posted looked very much like a memory
>> corruption problem. Were you running vanilla 2.4.22 on the
>> client, or was it too patched?
> It was also patched. I will try and reproduce the error with
> an unpatched kernel and a tcpdump running.
Please do...
Cheers,
Trond