[ceph-users] UID Restrictions

Keane Wolter wolterk at umich.edu
Wed Nov 1 11:06:00 PDT 2017

I have ownership of the directory /user/kwolter on the cephFS server and I
am mounting to ~/ceph, which I also own.

On Wed, Nov 1, 2017 at 2:04 PM, Gregory Farnum <gfarnum at redhat.com> wrote:

> Which directory do you have ownership of? Keep in mind your local
> filesystem permissions do not get applied to the remote CephFS mount...
> On Wed, Nov 1, 2017 at 11:03 AM Keane Wolter <wolterk at umich.edu> wrote:
>> I am mounting a directory under /user which I am the owner of with the
>> permissions of 700. If I remove the uid=100026 option, I have no issues. I
>> start having issues as soon as the uid restrictions are in place.
>> On Wed, Nov 1, 2017 at 1:05 PM, Gregory Farnum <gfarnum at redhat.com>
>> wrote:
>>> Well, obviously UID 100026 needs to have the normal POSIX permissions to
>>> write to the /user path, which it probably won't until after you've done
>>> something as root to make it so...
>>> On Wed, Nov 1, 2017 at 9:57 AM Keane Wolter <wolterk at umich.edu> wrote:
>>>> Acting as UID 100026, I am able to successfully run ceph-fuse and mount
>>>> the filesystem. However, as soon as I try to write a file as UID 100026, I
>>>> get permission denied, but I am able to write to disk as root without
>>>> issue. I am looking for the inverse of this. I want to write changes to
>>>> disk as UID 100026, but not as root. From what I understood in the email at
>>>> http://lists.ceph.com/pipermail/ceph-users-ceph.com/
>>>> 2017-February/016173.html, I should be able to do so with the
>>>> following cephx caps set to "caps: [mds] allow r, allow rw path=/user
>>>> uid=100026". Am I wrong with this assumption or is there something else at
>>>> play I am not aware of?
>>>> Thanks,
>>>> Keane
>>>> On Wed, Oct 25, 2017 at 5:52 AM, Gregory Farnum <gfarnum at redhat.com>
>>>> wrote:
>>>>> On Mon, Oct 23, 2017 at 5:03 PM Keane Wolter <wolterk at umich.edu>
>>>>> wrote:
>>>>>> Hi Gregory,
>>>>>> I did set the cephx caps for the client to:
>>>>>> caps: [mds] allow r, allow rw uid=100026 path=/user, allow rw
>>>>>> path=/project
>>>>> So you’ve got three different permission granting clauses here:
>>>>> 1) allows the client to read anything
>>>>> 2) allows the client to act as uid 100026 in the path /user
>>>>> 3) allows the user to do any read or write (as any user) in path
>>>>> /project
>>>>> caps: [mon] allow r
>>>>>> caps: [osd] allow rw pool=cephfs_osiris, allow rw pool=cephfs_users
>>>>>> Keane
>>>>>> On Fri, Oct 20, 2017 at 5:35 PM, Gregory Farnum <gfarnum at redhat.com>
>>>>>> wrote:
>>>>>>> What did you actually set the cephx caps to for that client?
>>>>>>> On Fri, Oct 20, 2017 at 8:01 AM Keane Wolter <wolterk at umich.edu>
>>>>>>> wrote:
>>>>>>>> Hello all,
>>>>>>>> I am trying to limit what uid/gid a client is allowed to run as
>>>>>>>> (similar to NFS' root squashing). I have referenced this email,
>>>>>>>> http://lists.ceph.com/pipermail/ceph-users-ceph.com/
>>>>>>>> 2017-February/016173.html, with no success.  After generating the
>>>>>>>> keyring, moving it to a client machine, and mounting the filesystem with
>>>>>>>> ceph-fuse, I am still able to create files with the UID and GID of root.
>>>>>>>> Is there something I am missing or can do to prevent root from
>>>>>>>> working with a ceph-fuse mounted filesystem?
>>>>>>>> Thanks,
>>>>>>>> Keane
>>>>>>>> wolterk at umich.edu
>>>>>>>> _______________________________________________
>>>>>>>> ceph-users mailing list
>>>>>>>> ceph-users at lists.ceph.com
>>>>>>>> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ceph.com/pipermail/ceph-users-ceph.com/attachments/20171101/20666039/attachment.html>

More information about the ceph-users mailing list