[Bugs] [Bug 1392772] [setxattr_cbk] "Permission denied" warning messages are seen in logs while running pjd-fstest suite

[bugzilla at redhat.com]

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

Raghavendra G <rgowdapp at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rgowdapp at redhat.com



--- Comment #3 from Raghavendra G <rgowdapp at redhat.com> ---
Seems like more investigation is needed on the RCA. Posting the email
conversation we had.


> Sent: Tuesday, November 22, 2016 9:22:09 AM
> Subject: Re: On patch #15794
> 
> On 22 November 2016 at 09:19, Raghavendra Gowdappa <rgowdapp at redhat.com>
> wrote:
> 
> >
> >
> > > Sent: Monday, November 21, 2016 8:36:49 PM
> > > Subject: On patch #15794
> > >
> > > Hi Nithya/Shyam,
> > >
> > > While thinking about patch [1], it occurred to me that if a user has
> > > permission to create directory, same credentials should be good enough to
> > > set layout xattrs too. However, I realized that layout xattrs start with
> > > "trusted." and only superuser can read/set them.
> >
> > Going by the above logic, we should've superuser access for setting all
> > other gluster metadata too (like gfid, afr changelog etc). But we don't
> > sudo to superuser while doing so. Also, from man 7 xattr,
> >
> > <man 7 xattr>
> >  Trusted extended attributes
> >        Trusted extended attributes are visible and accessible only to
> >        processes that have the CAP_SYS_ADMIN capability.  Attributes in
> > this
> >        class are used to implement mechanisms in user space (i.e., outside
> >        the kernel) which keep information in extended attributes to which
> >        ordinary processes should not have access.
> > </man>
> >
> > So, it seems that any process with CAP_SYS_ADMIN capability can set the
> > xattrs. It _seems_ (I am not confirming) that brick process retains that
> > capability even though we do setfsuid/gid (frame->root->uid/gid) (uid/gid
> > of process doing fops like mkdir etc, not the uid/gid of brick process). If
> > this indeed is true, we are missing something as to why mkdir failed with
> > EPERM.
> >
> >
> mkdir is created with the permissions specified in the command. So I guess
> the user would no longer have permissions to modify it (say set an xattr)
> if the op comes in as the same uid.

If that is indeed the case, its puzzling that the test I posted in my first
mail passed. I've a feeling that we are missing out something and more
investigation is needed here.

> 
> Ideally, all internal ops should be marked internal_fop and no security
> checks should hold in that case. The security implications of this need to
> be determined.
> 
> 
> 
> > As to why lookup path in dht does SUDO but not ops like mkdir/rmdir, it
> > might be because lookup can be executed by a process with just read
> > permission or process with no permission to access the directory. However,
> > that might not be the case with mkdir/rmdir codepath.
> >
> > > However on testing I was
> > > able to create a directory as non-root user. Note that the exported
> > > directory is owned by "raghu:users".
> > >
> > >
> > > [raghu at unused glusterfs]$ mkdir dir
> > >
> > > [raghu at unused glusterfs]$ whoami
> > > raghu
> > >
> > > [raghu at unused glusterfs]$ getfattr -e hex -d -m. /home/export/newptop
> > > getfattr: Removing leading '/' from absolute path names
> > > # file: home/export/newptop
> > > security.selinux=0x756e636f6e66696e65645f753a6f
> > 626a6563745f723a686f6d655f726f6f745f743a733000
> > >
> > > [raghu at unused glusterfs]$ getfattr -e hex -d -m.
> > /home/export/newptop/dir
> > > getfattr: Removing leading '/' from absolute path names
> > > # file: home/export/newptop/dir
> > > security.selinux=0x756e636f6e66696e65645f753a6f
> > 626a6563745f723a686f6d655f726f6f745f743a733000
> > >
> > > [raghu at unused glusterfs]$ sudo getfattr -e hex -d -m.
> > > /home/export/newptop/dir
> > > [sudo] password for raghu:
> > > getfattr: Removing leading '/' from absolute path names
> > > # file: home/export/newptop/dir
> > > security.selinux=0x756e636f6e66696e65645f753a6f
> > 626a6563745f723a686f6d655f726f6f745f743a733000
> > > trusted.gfid=0x17f753292e4b46c58b736d3a975af0dc
> > > trusted.glusterfs.dht=0x000000010000000000000000ffffffff
> > >
> > > [raghu at unused glusterfs]$ cd ..
> > >
> > > [raghu at unused mnt]$ cd /home/
> > >
> > > [raghu at unused home]$ cd
> > >
> > > [raghu at unused ~]$ mkdir tmp
> > >
> > > [raghu at unused ~]$ setfattr -n trusted.glusterfs.dht -v
> > > 0x000000010000000000000000ffffffff tmp
> > > setfattr: tmp: Operation not permitted
> > >
> > > [raghu at unused ~]$ ls -ld tmp
> > > drwxrwxr-x. 2 raghu raghu 4096 Nov 21 20:25 tmp
> > >
> > > Note that last setfattr on backend fs failed with EPERM.
> > >
> > > Now the puzzling thing is how mkdir by a non-root user succeeded on
> > glusterfs
> > > with appropriate xattrs set. Any explanations?
> > >
> > > [1] http://review.gluster.org/#/c/15794/
> > >
> > > regards,
> > > Raghavendra
> >
>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=g5EDoQfDgf&a=cc_unsubscribe