All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH 0/4] export/fuse: Allow other users access to the export
Date: Mon, 21 Jun 2021 19:18:17 +0200	[thread overview]
Message-ID: <9af03389-8c6d-6610-9326-61c65e8eac30@redhat.com> (raw)
In-Reply-To: <YNC6Xvcc9lKc50Sk@redhat.com>

On 21.06.21 18:12, Kevin Wolf wrote:
> Am 14.06.2021 um 16:44 hat Max Reitz geschrieben:
>> Hi,
>>
>> With the default mount options, FUSE mounts are not accessible to any
>> users but the one who did the mount, not even to root.  To allow such
>> accesses, allow_other must be passed.
>>
>> This is probably useful to some people (it certainly is to me, e.g. when
>> exporting some image as my normal user, and then trying to loop mount it
>> as root), so this series adds a QAPI allow-other bool that will make the
>> FUSE export code pass allow_other,default_permissions to FUSE.
>>
>> (default_permissions will make the kernel do the usual UNIX permission
>> checks, which is something that makes a lot of sense when allowing other
>> users access to the export.)
>>
>> This also requires our SETATTR code to be able to handle permission
>> changes, though, so the user can then run chmod/chown/chgrp on the
>> export to adjust its permissions to their need.
>>
>> The final patch adds a test.
> If there is even a use case for leaving the option off (not trusting
> root?), it must certainly be the less common case? So I'm not sure if
> allow-other should be an option at all, but if it is, enabling it by
> default would make more sense to me.
>
> Is there a reason why you picked false as the default, except that it is
> the old behaviour?

No. :)

Well, mostly.  I also thought, if FUSE thinks allow_other shouldn’t be 
the default, who am I to decide otherwise.

Now that I tried to find out why FUSE has it as the default (I only 
remember vague “security reasons”), I still couldn’t find out why, but I 
did find that using this option as non-root user requires /etc/fuse.conf 
to have user_allow_other in it, which I don’t think we can require.

So I think it must be an option.  As for which value should be the 
default, that probably depends on how common having user_allow_other in 
/etc/fuse.conf is.  I know I never put it there, and it’s both on my 
Fedora and my Arch system.  So I guess it seems rather common?

Max



      reply	other threads:[~2021-06-21 17:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 14:44 [PATCH 0/4] export/fuse: Allow other users access to the export Max Reitz
2021-06-14 14:44 ` [PATCH 1/4] export/fuse: Add allow-other option Max Reitz
2021-06-22 15:00   ` Kevin Wolf
2021-06-14 14:44 ` [PATCH 2/4] export/fuse: Give SET_ATTR_SIZE its own branch Max Reitz
2021-06-22 15:01   ` Kevin Wolf
2021-06-14 14:44 ` [PATCH 3/4] export/fuse: Let permissions be adjustable Max Reitz
2021-06-22 15:02   ` Kevin Wolf
2021-06-22 15:22     ` Max Reitz
2021-06-22 16:34       ` Kevin Wolf
2021-06-14 14:44 ` [PATCH 4/4] iotests/308: Test allow-other Max Reitz
2021-06-22 15:08   ` Kevin Wolf
2021-06-22 15:32     ` Max Reitz
2021-06-21 16:12 ` [PATCH 0/4] export/fuse: Allow other users access to the export Kevin Wolf
2021-06-21 17:18   ` Max Reitz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9af03389-8c6d-6610-9326-61c65e8eac30@redhat.com \
    --to=mreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.