[ Re-adding the list. ] On Wed, Sep 2, 2015 at 4:29 PM, Erming Pei <erming@xxxxxxxxxxx> wrote: > Hi Gregory, > > Thanks very much for the confirmation and explanation. > >>And I presume you have an MDS cap in there as well? > Is there a difference between set this cap and without setting? Well, I don't think you can access the MDS without a read cap, but maybe it's really just null... > >>I think you'll find that the data you've overwritten isn't really written >> to the OSDs — you wrote it in the local page cache, but the OSDs will reject >> the writes with EPERM. > I see. Is there a way for me to verify that, i.e., see there is not a > change to the data is OSDs? I found I can overwrite a file and then I can > see the file is changed. It may be in the local cache. But how can I test > and retrieve one in the OSD pool? Mounting it on another client and seeing if changes are reflected there would do it. Or unmounting the filesystem, mounting again, and seeing if the file has really changed. -Greg > > Thanks! > > Erming > > > > On 9/2/15, 2:44 AM, Gregory Farnum wrote: >> >> On Tue, Sep 1, 2015 at 9:20 PM, Erming Pei <erming@xxxxxxxxxxx> wrote: >>> >>> Hi, >>> >>> I tried to set up a read-only permission for a client but it looks >>> always >>> writable. >>> >>> I did the following: >>> >>> ==Server end== >>> >>> [client.cephfs_data_ro] >>> key = AQxxxxxxxxxx== >>> caps mon = "allow r" >>> caps osd = "allow r pool=cephfs_data, allow r >>> pool=cephfs_metadata" >> >> The clients don't directly access the metadata pool at all so you >> don't need to grant that. :) And I presume you have an MDS cap in >> there as well? >> >>> >>> ==Client end== >>> mount -v -t ceph hostname.domainname:6789:/ /cephfs -o >>> name=cephfs_data_ro,secret=AQxxxxxxxxxx== >>> >>> But I still can touch, delete, overwrite. >>> >>> I read that touch/delete could be only meta data operations, but why I >>> still >>> can overwrite? >>> >>> Is there anyway I could test/check the data pool (instead of meta data) >>> to >>> see if any effect on it? >> >> What you're seeing here is an unfortunate artifact of the page cache >> and the way these user capabilities work in Ceph. As you surmise, >> touch/delete are metadata operations through the MDS and in current >> code you can't block the client off from that (although we have work >> in progress to improve things). I think you'll find that the data >> you've overwritten isn't really written to the OSDs — you wrote it in >> the local page cache, but the OSDs will reject the writes with EPERM. >> I don't remember the kernel's exact behavior here though — we updated >> the userspace client to preemptively check access permissions on new >> pools but I don't think the kernel ever got that. Zheng? >> -Greg > > > > -- > --------------------------------------------- > Erming Pei, Ph.D > Senior System Analyst; Grid/Cloud Specialist > > Research Computing Group > Information Services & Technology > University of Alberta, Canada > > Tel: +1 7804929914 Fax: +1 7804921729 > --------------------------------------------- > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |