Re: silent semantic changes with reiser4

[Pavel Machek <pavel@ucw.cz>]

Hi!

I'm talking about uservfs.sf.net, aka podfuk, which implements tarfs
(and more).

> Leaving aside the obvious complexities of making sure the user space
> daemon doesn't just do something crazy, you have a number of problems:
> 
> * Which user does the daemon run as?  If it runs as root, it needs to
>   enforce strict security requirements in terms of VFS operations coming
>   in, and also, it has all the problems of a SUID application running on
>   an arbitrary user file.  I don't know about you, but I don't trust
>   joebob's tarfsd to be suid when running on some script kiddie tarball.

It needs to run as root. If there's bug in tar, that script kiddie is going
to get your users anyway. Audit the code.

> * If the daemon runs as a user, then what happens if you try to run a

It does not.

> * Consider what happens if foo.tar/blah_blah is automatically bound to
>   enter a tarfsd view of foo.tar.  What happens if I point the web
>   server at foo.tar/blah?  The web server runs as httpd or something, so
>   presumably httpd ends up running some sort of tarfsd view on the
>   file.  But if the tarball was made by a malicious person, presumably
>   it can obtain httpd user access now by exploiting a bug in tarfsd.

If there's a bug in tar, I can do a lot of interesting things. Audit tar.

> * Even if you assume the view is read-only and the kernel coerces all
>   permissions and ownership and such, there's the possibility of tarfsd
>   presenting unexpected syscall results - weird error codes, short
>   reads, file data changing underneath mmap, etc. that user applications
>   don't expect and may be susceptible to.

FUD. Fix tarfsd if its problem.

> * Besides all these security issues, if this scheme is writable it has

There are no security issues. Yes, uservfs is security-sensitive code.

>   all the resource problems that loopback network filesystems suffer.
>   What if the kernel is short on memory and tries to flush dirty buffers
>   to reclaim it.  If those buffers are running against the user FS
>   daemon, then that daemon must wake up to clear dirty buffers.  If it
>   tries to allocate memory, deadlock in the kernel.

Coda solves this: all writable things are file-backed on file in /tmp =>
bad performance if you only need piece of very large file,
but no deadlocks.

> Probably the security problems can be solved to some degree by being
> very paranoid in the kernel (at an associated loss in utility), and the
> resource issues can be solved by restricting dirty buffers for loopback
> mounts (at an associated loss in performance), but it's hardly simple.

See sources. It is <1000 lines of code.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms