Quantcast

mount option default_permissions

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

mount option default_permissions

Hans Beckerus
Hello, my high-level file system has always enforced the use of the
'default_permissions' mount option.
Now I got several users reporting problems with mounts exported across
e.g. network shares that behaves a bit odd.
It does not seem to help when using allow_other either. I have no
specific permission checks in my code.
Would it still be safe to leave out default_permissions, because that
seems to be the one things that helps most (if not all) users.

Thanks.
Hans

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mount option default_permissions

Hans Beckerus
On 2017-02-11 3:13, Hans Beckerus wrote:

> Hello, my high-level file system has always enforced the use of the
> 'default_permissions' mount option.
> Now I got several users reporting problems with mounts exported across
> e.g. network shares that behaves a bit odd.
> It does not seem to help when using allow_other either. I have no
> specific permission checks in my code.
> Would it still be safe to leave out default_permissions, because that
> seems to be the one things that helps most (if not all) users.
>
> Thanks.
> Hans
Any one that could tell me if it should be ok to leave this out? What is
the drawback by not using -odefault_permissions?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mount option default_permissions

Hans Beckerus
For some reason my membership has been revoked due to excessive bouncing. I hope my question reach the list now.

Thanks.
Hans


> 14 feb. 2017 kl. 20:47 skrev Hans Beckerus <[hidden email]>:
>
>> On 2017-02-11 3:13, Hans Beckerus wrote:
>> Hello, my high-level file system has always enforced the use of the 'default_permissions' mount option.
>> Now I got several users reporting problems with mounts exported across e.g. network shares that behaves a bit odd.
>> It does not seem to help when using allow_other either. I have no specific permission checks in my code.
>> Would it still be safe to leave out default_permissions, because that seems to be the one things that helps most (if not all) users.
>>
>> Thanks.
>> Hans
> Any one that could tell me if it should be ok to leave this out? What is the drawback by not using -odefault_permissions?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mount option default_permissions

Hans Beckerus
In reply to this post by Hans Beckerus
On 2017-02-14 9:11, Antonio SJ Musumeci wrote:
As the documentation mentions the option when enabled causes the kernel to do the permission checks. IE... based on what has already been returned to the kernel from getattr. If not enabled it's your responsibility to manage checking of permissions. The kernel and FUSE just pass the request to your code and if there is a permission issue you should return -EPERM or -EACCES.
Thanks, that helped a bit but not all the way :( I did read the documentation, but what effects it might have to omit this option is still unknown to me. All I know is that it seems to help to not use this option for some users experiencing access problem over e.g. Samba. But I am a bit reluctant to remove it by default unless I understand exactly what negative effects that would have.

On Tue, Feb 14, 2017 at 2:47 PM, Hans Beckerus <[hidden email]> wrote:
On 2017-02-11 3:13, Hans Beckerus wrote:
> Hello, my high-level file system has always enforced the use of the
> 'default_permissions' mount option.
> Now I got several users reporting problems with mounts exported across
> e.g. network shares that behaves a bit odd.
> It does not seem to help when using allow_other either. I have no
> specific permission checks in my code.
> Would it still be safe to leave out default_permissions, because that
> seems to be the one things that helps most (if not all) users.
>
> Thanks.
> Hans
Any one that could tell me if it should be ok to leave this out? What is
the drawback by not using -odefault_permissions?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mount option default_permissions

Antonio SJ Musumeci-2
The effect is that you only have the entitlements which you've implemented explicitly. 

If you have none... you'll have no entitlements with it disabled. 

On Feb 15, 2017 2:37 PM, "Hans Beckerus" <[hidden email]> wrote:
On 2017-02-14 9:11, Antonio SJ Musumeci wrote:
As the documentation mentions the option when enabled causes the kernel to do the permission checks. IE... based on what has already been returned to the kernel from getattr. If not enabled it's your responsibility to manage checking of permissions. The kernel and FUSE just pass the request to your code and if there is a permission issue you should return -EPERM or -EACCES.
Thanks, that helped a bit but not all the way :( I did read the documentation, but what effects it might have to omit this option is still unknown to me. All I know is that it seems to help to not use this option for some users experiencing access problem over e.g. Samba. But I am a bit reluctant to remove it by default unless I understand exactly what negative effects that would have.

On Tue, Feb 14, 2017 at 2:47 PM, Hans Beckerus <[hidden email]> wrote:
On 2017-02-11 3:13, Hans Beckerus wrote:
> Hello, my high-level file system has always enforced the use of the
> 'default_permissions' mount option.
> Now I got several users reporting problems with mounts exported across
> e.g. network shares that behaves a bit odd.
> It does not seem to help when using allow_other either. I have no
> specific permission checks in my code.
> Would it still be safe to leave out default_permissions, because that
> seems to be the one things that helps most (if not all) users.
>
> Thanks.
> Hans
Any one that could tell me if it should be ok to leave this out? What is
the drawback by not using -odefault_permissions?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mount option default_permissions

Nikolaus Rath
In reply to this post by Hans Beckerus
On Feb 14 2017, Hans Beckerus <[hidden email]> wrote:

> On 2017-02-11 3:13, Hans Beckerus wrote:
>> Hello, my high-level file system has always enforced the use of the
>> 'default_permissions' mount option.
>> Now I got several users reporting problems with mounts exported across
>> e.g. network shares that behaves a bit odd.
>> It does not seem to help when using allow_other either. I have no
>> specific permission checks in my code.
>> Would it still be safe to leave out default_permissions, because that
>> seems to be the one things that helps most (if not all) users.
>
> Any one that could tell me if it should be ok to leave this out? What is
> the drawback by not using -odefault_permissions?

Well, I believe even if you do not use allow_others, this means some
operations that would normally fail will now succeed (unless you
implement permission checks in your filesystem).

For example, with default_permissions even the mounting user can't
delete files from a directory with 0550 permissions. Without it, he'd be
able to do so unless your filesystem prevents it.

Best,
-Nikolaus

--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...