lkml.org 
[lkml]   [2005]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] private mounts
Hi!

> > > Is it possible to limit all these from kernelspace? Probably yes,
> > > although a timeout for operations is something that cuts either way.
> > > And the compexity of these checks would probably be orders of
> > > magnitude higher then the check we are currently discussing.
> >
> > Yes ... but does the check we are discussing really solve the
> > problem?
> >
> > Let's say that you attempt to export home directories of users by a
> > user-space NFS daemon. This daemon probably changes its fsuid to
> > match the remote user, so the check happily accepts the access and
> > the user is able to lock up the daemon.
>
> Valid point. The only defense is that when a program set's fsuid,
> it's performing the operation "on behalf of the user". So the user is
> actually doing DoS against himself.
>
> Of course this is not strictly true. E.g. in the userspace NFS case
> it's probably a DoS against all users of the mount.

Exactly. So can we simply merge root-only fuse, and then worry
how to make it safe with user-mounted fuse. See your own unfsd example
why user-mounting is bad.

One possible solution would be to have root-owned fused that
talks to user-owned fused-s and checks they are behaving correctly?

Second is somehow improving those two lines this long thread is all about...

Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms

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

\
 
 \ /
  Last update: 2005-04-28 20:20    [W:1.688 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site