[Bugs] [Bug 1666326] New: reopening bug 1405147: Failed to dispatch handler: glusterfs seems to check for "write permission" instead for "file owner" during open() when writing to a file

bugzilla at redhat.com bugzilla at redhat.com
Tue Jan 15 14:06:57 UTC 2019


https://bugzilla.redhat.com/show_bug.cgi?id=1666326

            Bug ID: 1666326
           Summary: reopening bug 1405147: Failed to dispatch handler:
                    glusterfs seems to check for "write permission"
                    instead for "file owner" during open() when writing to
                    a file
           Product: GlusterFS
           Version: 5
          Hardware: x86_64
                OS: Linux
            Status: NEW
         Component: open-behind
          Severity: high
          Assignee: bugs at gluster.org
          Reporter: omar at dit.upm.es
                CC: bugs at gluster.org
  Target Milestone: ---
    Classification: Community



Description of problem:
When using trough NFS a fuse-mounted glusterfs volume, an error is found if the
owner of a file (that is not root) tries to write data in its own file when it
has read-only permissions.

The problem does not exist if the user is root.

Version-Release number of selected component (if applicable):
All versions tested (glusterfs-3.7.{4-16}, glusterfs-3.8.{4-5}), glusterfs-5.2

How reproducible:
Always

Steps to Reproduce:

Our architecture has 3 layers: the glusterfs servers layer, an intermediate
server for reexporting it via NFS, and the final nfs client at the lab.

1. Mount with nfs (at the client) a fuse mounted glusterfs volume exported via
nfs (at the intermediate server) to be the home of the user.

cd to home dir and check that the volume is mounted and the file that we will
use for testing does not exist:
user at computer:~$ ls -l dest.txt
ls: cannot access dest.txt: No such file or directory
user at computer:~$

2a. Simple test with few logs:

Create a readonly file and try to write data in it. You can execute the
following multi-command (error comes at echo, not before). Rm is there only for
repetition purposes:

user at computer:~$ rm -f 444.txt; touch 444.txt; chmod 444 444.txt; echo test >
444.txt
-bash: 444.txt: Permission denied

This command fails but does not render information in the glusterfs client log
of the NFS intermediate server. Only in the glusterfs server log:

The message "E [MSGID: 101191] [event-epoll.c:671:event_dispatch_epoll_worker]
0-epoll: Failed to dispatch handler" repeated 14 times between [2019-01-15
13:48:17.999280] and [2019-01-15 13:49:45.530578]

2b. Test with more logs available (error shows up when executing cp):

user at computer:~$ rm -f 444.txt dest.txt; echo test > 444.txt; chmod 444
444.txt; cp -p 444.txt dest.txt;
cp: failed to close 'dest.txt': Permission denied

Messages at the glusterfs client log of the NFS intermediate server:
[2019-01-15 13:50:05.955944] I [io-stats.c:1667:io_stats_dump_fd]
0-distribuido3468: --- fd stats ---
[2019-01-15 13:50:05.957628] I [io-stats.c:1670:io_stats_dump_fd]
0-distribuido3468:       Filename : /home/user/444.txt
[2019-01-15 13:50:05.959198] I [io-stats.c:1684:io_stats_dump_fd]
0-distribuido3468:   BytesWritten : 5 bytes
[2019-01-15 13:50:05.959217] I [io-stats.c:1698:io_stats_dump_fd]
0-distribuido3468: Write 000004b+ : 1
[2019-01-15 13:50:05.984823] E [MSGID: 114031]
[client-rpc-fops_v2.c:281:client4_0_open_cbk] 0-distribuido3468-client-1:
remote operation failed. Path: /home/user/dest.txt
(25be0793-520e-4a87-9b34-f1b9f633af42) [Permission denied]
[2019-01-15 13:50:05.989937] W [fuse-bridge.c:1124:fuse_fd_cbk]
0-glusterfs-fuse: 1481: OPEN() /home/user/dest.txt => -1 (Permission denied)

Messages at the glusterfs server:
[2019-01-15 13:50:05.931054] E [MSGID: 101191]
[event-epoll.c:671:event_dispatch_epoll_worker] 0-epoll: Failed to dispatch
handler
[2019-01-15 13:50:05.956175] I [io-stats.c:1667:io_stats_dump_fd]
0-distribuido3468-io-stats: --- fd stats ---
[2019-01-15 13:50:05.958417] I [io-stats.c:1670:io_stats_dump_fd]
0-distribuido3468-io-stats:       Filename : /home/user/444.txt
[2019-01-15 13:50:05.961269] I [io-stats.c:1684:io_stats_dump_fd]
0-distribuido3468-io-stats:   BytesWritten : 5 bytes
[2019-01-15 13:50:05.961372] I [io-stats.c:1698:io_stats_dump_fd]
0-distribuido3468-io-stats: Write 000004b+ : 1
The message "E [MSGID: 101191] [event-epoll.c:671:event_dispatch_epoll_worker]
0-epoll: Failed to dispatch handler" repeated 2 times between [2019-01-15
13:50:05.931054] and [2019-01-15 13:50:05.942111]


3. Check result: desired file is empty.
user at computer:~$ ls -l 444.txt
-r--r--r-- 1 user user 0 dic 15  2016 444.txt
user at computer:~$ rm -f 444.txt
user at computer:~$

4. Check that the problem dissapears with root privileges:
user at computer:~$ sudo su
root at computer:/home/user# rm -f 444.txt; touch 444.txt; chmod 444 444.txt; echo
test > 444.txt
root at computer:/home/user# ls -l 444.txt
-r--r--r-- 1 root root 5 dic 15  2016 444.txt
root at computer:/home/user# rm -f 444.txt
root at computer:/home/user#

Actual results:
A user who owns a file that is read-only cannot write into it under the
described circumstances.

Expected results:
A user who owns a file that is read-only should be able to write into it even
if it is read-only.

Additional info:
Special thanks to Bruce Fields and other components of nfs-kernel-server team
because initially we thought it was their fault. The same to Soumya Koduri and
Miklos Szeredi, that helped to confirm the problem.

See full previous thread on nfs-kernel-server list with history about the
issue:
http://marc.info/?t=144801803400001 (for posterity's sake, permanent link:
http://marc.info/?i=862ef8b0-61ee-8b7e-a81c-fcdc5a726e37@dit.upm.es).

This bug is reopened because the team thought that was fixed in glusterfs-5.0.
See previous bug report at:
https://bugzilla.redhat.com/show_bug.cgi?id=1405147.

Presentation (in Spanish, 2015) about the lab config and some tests:
http://www.rediris.es/jt/jt2015/ponencias/?id=jt2015-jt-ses_4b_seg_red_camp_2-a17b2c1.pdf

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list