[ceph-users] UID Restrictions

Keane Wolter wolterk at umich.edu
Thu Nov 2 15:14:50 PDT 2017


Awesome!

Thanks much again.

Keane

On Thu, Nov 2, 2017 at 5:23 PM, Douglas Fuller <dfuller at redhat.com> wrote:

> Hi Keane,
>
> No problem. A fix for the gids bug should go in shortly. See:
> https://github.com/ceph/ceph/pull/18689
>
> Cheers,
> --Doug
>
> On Thu, Nov 2, 2017 at 4:24 PM Keane Wolter <wolterk at umich.edu> wrote:
>
>> Here we go. removing the trailing slash and adding the gids parameter in
>> auth caps works.
>>
>> [kwolter at um-test03 ~]$ sudo ceph auth get-or-create-key
>> client.kwolter_test1 mon 'allow r' mds 'allow r, allow rw path=/user
>> uid=100026 gids=100026' osd 'allow rw pool=cephfs_osiris, allow rw
>> pool=cephfs_users'
>> <key removed>
>> [kwolter at um-test03 ~]$ sudo ceph auth export client.kwolter_test1 >
>> ceph.client.kwolter_test1
>> export auth(<auid and key removed> with 3 caps)
>> [kwolter at um-test03 ~]$ mv ceph.client.kwolter_test1
>> ceph.client.kwolter_test1.keyring
>> [kwolter at um-test03 ~]$ sudo ceph-fuse --id=kwolter_test1 -k
>> ./ceph.client.kwolter_test1.keyring -r /user/kwolter
>> --client-die-on-failed-remount=false ceph
>> ceph-fuse[3458051]: starting ceph client
>> ceph-fuse[3458051]: starting fuse
>> [kwolter at um-test03 ~]$
>>
>> [kwolter at um-test03 ~]$ touch ceph/test.txt
>> [kwolter at um-test03 ~]$ ls -lt test.txt
>> -rw-rw-r-- 1 kwolter kwolter 0 Nov  2 16:20 test.txt
>> [kwolter at um-test03 ~]$ sudo touch ceph/test2.txt
>> touch: cannot touch ‘ceph/test2.txt’: Permission denied
>> [kwolter at um-test03 ~]$
>>
>> [kwolter at um-test03 ~]$ sudo umount ceph
>> [kwolter at um-test03 ~]$
>>
>> Thank you very much!
>>
>> Keane
>>
>> On Thu, Nov 2, 2017 at 3:51 PM, Douglas Fuller <dfuller at redhat.com>
>> wrote:
>>
>>> Looks like there may be a bug here.
>>>
>>> Please try:
>>>
>>> * Removing the trailing slash from path= (needs documentation or fixing)
>>> * Adding your gid to a “gids” parameter in the auth caps? (bug: we’re
>>> checking the gid when none is supplied)
>>>
>>> mds “allow r, allow rw path=/user uid=100026 gids=100026<or whatever>”
>>>
>>> Please let me know if that works and I’ll file a bug.
>>>
>>> Thanks,
>>> —Doug
>>>
>>> > On Nov 2, 2017, at 2:48 PM, Keane Wolter <wolterk at umich.edu> wrote:
>>> >
>>> > Hi Doug,
>>> >
>>> > Here is the output:
>>> > [kwolter at um-test03 ~]$ sudo ceph auth get client.kwolter_test1
>>> > exported keyring for client.kwolter_test1
>>> > [client.kwolter_test1]
>>> >         key = <removed>
>>> >         caps mds = "allow r, allow rw path=/user/ uid=100026"
>>> >         caps mon = "allow r"
>>> >         caps osd = "allow rw pool=cephfs_osiris, allow rw
>>> pool=cephfs_users"
>>> > [kwolter at um-test03 ~]$
>>> >
>>> > As for the logs, the only lines I get are about the ceph-fuse being
>>> mounted.
>>> > 2017-11-02 14:45:53.246388 7f72d7a9e040  0 ceph version 12.2.1
>>> (<removed>) luminous (stable), process (unknown), pid 3454195
>>> > 2017-11-02 14:45:53.247947 7f72d7a9e040  0 pidfile_write: ignore empty
>>> --pid-file
>>> > 2017-11-02 14:45:53.251078 7f72d7a9e040 -1 init, newargv =
>>> 0x55e035f524c0 newargc=9
>>> >
>>> > Thanks,
>>> > Keane
>>> >
>>> >
>>> > On Thu, Nov 2, 2017 at 2:42 PM, Douglas Fuller <dfuller at redhat.com>
>>> wrote:
>>> > Hi Keane,
>>> >
>>> > Could you include the output of
>>> >
>>> > ceph auth get client.kwolter_test1
>>> >
>>> > Also, please take a look at your MDS log and see if you see an error
>>> from the file access attempt there.
>>> >
>>> > Thanks,
>>> > —Doug
>>> >
>>> > > On Nov 2, 2017, at 2:24 PM, Keane Wolter <wolterk at umich.edu> wrote:
>>> > >
>>> > > Hi Doug,
>>> > >
>>> > > Here is my current mds line I have for my user: caps: [mds] allow r,
>>> allow rw path=/user/ uid=100026. My results are as follows when I mount:
>>> > > sudo ceph-fuse --id=kwolter_test1 -k ./ceph.client.kwolter_test1.keyring
>>> -r /user/kwolter --client-die-on-failed-remount=false ceph
>>> > > ceph-fuse[3453714]: starting ceph client
>>> > > ceph-fuse[3453714]: starting fuse
>>> > > [kwolter at um-test03 ~]$
>>> > >
>>> > > I then get a permission denied when I try to add anything to the
>>> mount, even though I have matching UIDs:
>>> > > [kwolter at um-test03 ~]$ touch ceph/test.txt
>>> > > touch: cannot touch ‘ceph/test.txt’: Permission denied
>>> > > [kwolter at um-test03 ~]$ sudo touch ceph/test.txt
>>> > > touch: cannot touch ‘ceph/test.txt’: Permission denied
>>> > > [kwolter at um-test03 ~]$
>>> > >
>>> > > Thanks,
>>> > > Keane
>>> > >
>>> > > On Thu, Nov 2, 2017 at 1:15 PM, Douglas Fuller <dfuller at redhat.com>
>>> wrote:
>>> > > Hi Keane,
>>> > >
>>> > > path= has to come before uid=
>>> > >
>>> > > mds “allow r, allow rw path=/user uid=100026, allow rw path=/project"
>>> > >
>>> > > If that doesn’t work, could you send along a transcript of your
>>> shell session in setting up the ceph user, mounting the file system, and
>>> attempting access?
>>> > >
>>> > > Thanks,
>>> > > —Doug
>>> > >
>>> > > > On Nov 1, 2017, at 2:06 PM, Keane Wolter <wolterk at umich.edu>
>>> wrote:
>>> > > >
>>> > > > 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
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > 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/20171102/c784dedf/attachment.html>


More information about the ceph-users mailing list