| Summary: | group permissions broken in gluster client under openvz | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Need Real Name <george> |
| Component: | fuse | Assignee: | Csaba Henk <csaba> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.2.3 | CC: | aavati, amarts, gluster-bugs, vbellur, vijay |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Need Real Name
2011-09-16 00:34:35 UTC
Is this a reasonable workaround? The mapping of the pids that the kernel provides through the FUSE protocol to FUSE server that runs in an OpenVZ container should be done in-kernel. AFAICS OpenVZ adds only a generic compatibility glue to FUSE which makes it possible to use this kernel service from a container; no semantic fixes are provided. (For reference, as I checked, these are the OpenVZ modifications for FUSE: - For 2.6.18, ie. your kernel: http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=1e1b7d1 http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=9fd1662 http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=7a016ad http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=5f35bc7 - For 2.6.32, ie. latest kernel they support: http://git.openvz.org/?p=linux-2.6.32-openvz;a=commitdiff;h=8f48174c ) So I think the issue should be reported to / handled by the OpenVZ project. It would be possible to work this around in glusterfs code The mapping of the pids that the kernel provides through the FUSE protocol to FUSE server that runs in an OpenVZ container should be done in-kernel. AFAICS OpenVZ adds only a generic compatibility glue to FUSE which makes it possible to use this kernel service from a container; no semantic fixes are provided. (For reference, as I checked, these are the OpenVZ modifications for FUSE: - For 2.6.18, ie. your kernel: http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=1e1b7d1 http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=9fd1662 http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=7a016ad http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=5f35bc7 - For 2.6.32, ie. latest kernel they support: http://git.openvz.org/?p=linux-2.6.32-openvz;a=commitdiff;h=8f48174c ) So I think the issue should be reported to / handled by the OpenVZ project. @avati: should we provide a way to mount the fs with "default_permissions" and have the brick servers not do ACL? I know there is "--acl" glusterfs option that controls client behavior but why can we not control this for bricks? %%%%%%%%%%%%%%%%%%%% TL;DR: %%%%%%%%%%%%%%%%%%%%%%%%%%%% Therefore, if no objection raised against the above analysis, I will close this bug with RESOLVED/WONTFIX. For now, I set it to severity normal, as Glusterfs has no official support for OpenVZ. If we happen to agree that a "volume set"-able option is to be introduced to control brick's ACL loading, let that make a separate enhancement entry. No objection was raised by anyone against my claim that the fix for this issue is out of glusterfs' scope. |