I'm quite aware of all this. What I was asking for were those "security issues"
that you claim to be solved>by randomizing the inode-to-filehandle-relationship on every
server reboot.
I have not really wanted to spell it out.
The following is mainly about NFSv2/v3.
Client requests a File Han
I must admit getting somewhat tired of this discussion, but I simply don't want
people investigating the original problem being distracted.
EF> I'm a bit surprised by this. Which "discussion group"?
DA> The RFC, one for NFSv4.0
Oh, you mean you posted to n...@ietf.org? Oh yes,
http://www.nfsv4.o
Original Message by Edgar
I was part of the discussion group for NFSv4 spec
the short comings of v2 and v3 have been fixed
I'm a bit surprised by this. Which "discussion group"?
The RFC, one for NFSv4.0
NFSD (v2/v3) is stateless other than the information provid
On 3/17/2010 2:59 PM, Edgar Fuß wrote:
These web servers also use the nullfs mount which is actually a NFS
mount via the host machine to get the content that it serves to the
reverse proxy.
But Web servers usually don't delete or rename files, do they?
Some can depending on whether any
> These web servers also use the nullfs mount which is actually a NFS
> mount via the host machine to get the content that it serves to the
> reverse proxy.
But Web servers usually don't delete or rename files, do they?
> I was part of the discussion group for NFSv4 spec
> the short comings of v2 and v3 have been fixed
I'm a bit surprised by this. Which "discussion group"?
> NFSD (v2/v3) is stateless other than the information provided by
> mountd (mount requests) and lockd (file locking).
NFS is stateless save t
NFS Security 101 for NFSv2 and v3 (NOT NFSv4 a long time ago I was part
of the discussion group for NFSv4 spec the short comings of v2 and v3
have been fixed)
SRV: Server Exports File System /abc/123 access only to host=xyz.domain.com
XYZ: Client Mount mount's SRV:/abc/123
SRV: "mountd" gets a
On 17.3.2010, at 0.11, Joe wrote:
> I'm not sure if this helps at but it is how i have things set up.
Well, if you can't get it fixed on OS side, you can always patch Dovecot. I'm
just not sure if there's a way I could make this work well for everyone.
diff -r a1177c6cf8c7 src/deliver/deliver.c
I don't concur.
NFS is stateless and designed to survive server reboots (why would you have
stad otherwise?). What you do is inode randomization on the file system backing
the NFS export.
You get those stale handles when someone on the client has a file on the mount
open and some other way
> To fix (well work around) a security issue, for about 10+ years now,
> when a NFS server reboots, it generates a new random handle for the
> NFS Share. (sever may generate a new random handle per mount
> request)
I don't concur.
NFS is stateless and designed to survive server reboots (why would
On Wed, 2010-03-17 at 01:59 +1100, Damon Atkins wrote:
> In the old days NFS Shared Path had a static handle (ie a number),
> normal based on some number pulled out of the file system/inode.
> To fix (well work around) a security issue, for about 10+ years now,
> when a NFS server reboots, it gen
In the old days NFS Shared Path had a static handle (ie a number),
normal based on some number pulled out of the file system/inode.
To fix (well work around) a security issue, for about 10+ years now,
when a NFS server reboots, it generates a new random handle for the NFS
Share. (sever may gen
12 matches
Mail list logo
