Awesome! Thanks much again.
Keane On Thu, Nov 2, 2017 at 5:23 PM, Douglas Fuller <dful...@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 <wolt...@umich.edu> wrote: > >> Here we go. removing the trailing slash and adding the gids parameter in >> auth caps works. >> >> [kwolter@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@um-test03 ~]$ sudo ceph auth export client.kwolter_test1 > >> ceph.client.kwolter_test1 >> export auth(<auid and key removed> with 3 caps) >> [kwolter@um-test03 ~]$ mv ceph.client.kwolter_test1 >> ceph.client.kwolter_test1.keyring >> [kwolter@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@um-test03 ~]$ >> >> [kwolter@um-test03 ~]$ touch ceph/test.txt >> [kwolter@um-test03 ~]$ ls -lt test.txt >> -rw-rw-r-- 1 kwolter kwolter 0 Nov 2 16:20 test.txt >> [kwolter@um-test03 ~]$ sudo touch ceph/test2.txt >> touch: cannot touch ‘ceph/test2.txt’: Permission denied >> [kwolter@um-test03 ~]$ >> >> [kwolter@um-test03 ~]$ sudo umount ceph >> [kwolter@um-test03 ~]$ >> >> Thank you very much! >> >> Keane >> >> On Thu, Nov 2, 2017 at 3:51 PM, Douglas Fuller <dful...@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 <wolt...@umich.edu> wrote: >>> > >>> > Hi Doug, >>> > >>> > Here is the output: >>> > [kwolter@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@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 <dful...@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 <wolt...@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@um-test03 ~]$ >>> > > >>> > > I then get a permission denied when I try to add anything to the >>> mount, even though I have matching UIDs: >>> > > [kwolter@um-test03 ~]$ touch ceph/test.txt >>> > > touch: cannot touch ‘ceph/test.txt’: Permission denied >>> > > [kwolter@um-test03 ~]$ sudo touch ceph/test.txt >>> > > touch: cannot touch ‘ceph/test.txt’: Permission denied >>> > > [kwolter@um-test03 ~]$ >>> > > >>> > > Thanks, >>> > > Keane >>> > > >>> > > On Thu, Nov 2, 2017 at 1:15 PM, Douglas Fuller <dful...@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 <wolt...@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 <gfar...@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 <wolt...@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 <gfar...@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 <wolt...@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 < >>> gfar...@redhat.com> wrote: >>> > > > >>> > > > On Mon, Oct 23, 2017 at 5:03 PM Keane Wolter <wolt...@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 < >>> gfar...@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 <wolt...@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 >>> > > > wolt...@umich.edu >>> > > > _______________________________________________ >>> > > > ceph-users mailing list >>> > > > ceph-users@lists.ceph.com >>> > > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > _______________________________________________ >>> > > > ceph-users mailing list >>> > > > ceph-users@lists.ceph.com >>> > > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >>> > > >>> > > >>> > >>> > >>> >>> >>
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
