lkml.org 
[lkml]   [2014]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs only with a mount option
Michael j Theall <mtheall@us.ibm.com> writes:

> Seth Forshee <seth.forshee@canonical.com> wrote on 10/14/2014 09:25:55 AM:
>
>> From: Seth Forshee <seth.forshee@canonical.com>
>> To: Miklos Szeredi <miklos@szeredi.hu>
>> Cc: fuse-devel@lists.sourceforge.net, "Serge H. Hallyn"
>> <serge.hallyn@ubuntu.com>, linux-kernel@vger.kernel.org, Seth
>> Forshee <seth.forshee@canonical.com>, "Eric W. Biederman"
>> <ebiederm@xmission.com>, linux-fsdevel@vger.kernel.org
>> Date: 10/14/2014 09:27 AM
>> Subject: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs
>> only with a mount option
>>
>> Allowing unprivileged users to provide arbitrary xattrs via fuse
>> mounts bypasses the normal restrictions on setting xattrs. Such
>> mounts should be restricted to reading and writing xattrs in the
>> user.* namespace.
>>
>
> Can you explain how the normal restrictions on setting xattrs are
> bypassed?

If the fuse server is not run by root. Which is a large part of the
point of fuse.

> My filesystem still needs security.* and system.*, and it looks like
> xattr_permission already prevents non-privileged users from accessing
> trusted.*

If the filesystem is mounted with nosuid (typical of a non-privileged
mount of fuse) then the security.* attributes are ignored.

>> It's difficult though to tell whether a mount is being performed
>> on behalf of an unprivileged user since fuse mounts are ususally
>> done via a suid root helper. Thus a new mount option,
>> privileged_xattrs, is added to indicated that xattrs from other
>> namespaces are allowed. This option can only be supplied by
>> system-wide root; supplying the option as an unprivileged user
>> will cause the mount to fail.
>
> I can't say I'm convinced that this is the right direction to head.

With respect to defaults we could keep the current default if you
have the global CAP_SYS_ADMIN privilege when the mount takes place
and then avoid breaking anything.

Eric


\
 
 \ /
  Last update: 2014-10-14 22:41    [W:0.240 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site