> > + /*
> > +* For unprivileged mounts use current uid/gid. Still allow
> > +* "user_id" and "group_id" options for compatibility, but
> > +* only if they match these values.
> > +*/
> > + if (!capable(CAP_SYS_ADMIN)) {
> > + d->user_id = current->uid;
> > +
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
>
> FUSE was designed from the beginning to be safe for unprivileged
> users. This has also been verified in practice over many years. In
> addition un
> > Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
> >
> > FUSE was designed from the beginning to be safe for unprivileged
> > users. This has also been verified in practice over many years.
>
> How does FUSE do this?
>
> There are obvious cases like crafting a filesystem which has set
On Fri, 20 Apr 2007 12:25:40 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
>
> FUSE was designed from the beginning to be safe for unprivileged
> users. This has also been verified in practice over many years.
How does FUSE do this?
Th
From: Miklos Szeredi <[EMAIL PROTECTED]>
Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
FUSE was designed from the beginning to be safe for unprivileged
users. This has also been verified in practice over many years. In
addition unprivileged mounts require the parent mount to be owned b
5 matches
Mail list logo