Miklos Szeredi wrote:
- network/userspace filesystems should be fine aswell
They should, but again I wonder if NFS with all it's complexity is
being careful enough with what it accepts from the server.
That is the fun of trying to get our network filesystems up to the 20th
century. There is
at lot more work that has to be done here, but it is gradually
improving. At least for cifs
but probably for NFSv4 (and possibly AFS) it is possible for the client
to validate that the
server is who it says it is, and both NFSv4 (actually the newer NFS RPC)
and CIFS of course
allow packet signing which helps, not sure if AFS allows packet
signing. There does
need to be even more testing in one area though - selective packet
corruption testing
(which can be done by temporarily modifying the server to inject random
invalid packet
information on a subset of fields every thousand packets or so) since
the biggest danger
in network filesystems is the huge variety of servers with different
server bugs that you have
to be able to workaround. Working around server bugs is a huge problem with
the client side of networking code.
I take that back. Any filesystem using page cache and allowing shared
writable mapping is currently unsafe because of OOM deadlock if
mounted from local machine, or simply DoS against client by delaying
writeback.
So other than FUSE, what's left as safe?
Miklos
Don't see how FUSE is that much safer, if you allocate kernel memory at
all you eventually can create DoS,
and you can not do a filesystem without allocating some kernel memory,
but it does not seem that easy to
do intentionally. At least for the CIFS case you can turn off the page
cache for inode data on a per mount
basis (with the forcedirectio mount flag) if you worry about the server
intentionally holding up writes.
Unless the write is past end of file, writes are timed out reasonably
quickly anyway, and end up
killing the session, which depending on the setting of the hard/soft
flag probably should result in a page fault.
There is one remaining issue with mount and umount - the user space
utilities. By the way who maintains
them these days? Although the mount utilities allow filesystem
specific mount and umount helpers
to be placed in /sbin and automatically executed for the matching
filesystem type, there are a few functions
that belong in common code - in a system library which today have to be
implemented in every helper
function and of course are implemented in different ways in different
distros and
different tools with possibility of corruption of the /etc/mtab. It
may be that the file /etc/mtab
does not matter and that it needs to go away and everyone needs to look
at /proc/mounts instead, but
in the meantime /etc/mtab can easily get out of sync with the actual
list of mounts, although that
usuallly does not prevent unmount from working it may be confusing.
The basic problem is that the
"lock the mtab / add a new line to it / unlock" is not available in an
exported function (alternatively if
lock and unlock mtab functions were exported that would help) and
similarly with umount.there
is no "safely remove the matching line from mtab" - Looking at the
mount utils and various mount helper
functions it looks like you can not make any assumptions about the name
of the lock file used to protect
mtab (I am not even sure that you can guarantee that /etc/mtab is a
file, or even a symlink).
the lock file used to lock the mtab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
