Re: silent semantic changes with reiser4

[Elladan]

On Fri, Sep 10, 2004 at 03:22:59PM -0400, Timothy Miller wrote:
> 
> Linus Torvalds wrote:
> 
> >The same goes for something like a "container file". Whether you see it as
> >"dir-as-file" or "file-as-dir" (and I agree with Jan that the two are
> >totally equivalent), the point of having the capability in the kernel is
> >not that the operations cannot be done in user space - the point is that
> >they cannot be done in user space _safely_. The kernel is kind of the
> >thing that guarantees that everybody follows the rules.
> 
> Well, it CAN be done safely if every client has to go through the kernel 
> which does all the appropriate locks/semaphors and then passes the 
> request down to the daemon.  (Isn't NFS implemented this way?)
> 
> This is very micro-kernel-ish, but it's a reasonable idea to do it this 
> way in cases where things are non-critical.
> 
> Say there's a way to cd into a tgz file to look around.  If the access 
> methods through the kernel get routed back to a user-space process 
> (which probably does some amount of caching in memory and on disk of 
> uncompressed bits of the archive), it could be a bit slower than if it 
> were all in-kernel.  The thing is that the processing time in the daemon 
> is probably quite high compared to the overhead of the context switches, 
> so it doesn't cost much.  (And if it CAN be done in userspace without 
> being horribly convoluted or unsafe, then it SHOULD be done in 
> userspace.)  Besides, even if it were a LOT slower to access a tgz file 
> without extracting it first, I would STILL think it was wonderful AND 
> use it a LOT.

This is only safe for some limited definitions of safety.

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.

  If it runs as the user making the request, then what happens when two
  users try to open the same file at the same time.  Do they see two
  different views of the file?  Is one of them locked out?  How can they
  possibly synchronize if the views are writable?

* If the daemon runs as a user, then what happens if you try to run a
  suid program inside of the view?  What if root tries to walk into a
  tar file?  The conservative view is that the kernel would need to
  always return ENOENT for any process with elevated capabilities, but
  even this is not safe.

* 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.

* 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.

* Besides all these security issues, if this scheme is writable it has
  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.


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.

-J

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/