 |
 |
Hi Heiko, From the authorization prospect (after Xrootd authenticates the users), Xrootd does not have the concept of file ownership. If you go to the data servers, you will see that all files will be owned the process running the xrootd process. Xrootd uses ACL rules (as specified in your AuthFile) to control who has want control. Now, in authentication, Xrootd depends on various authentication module to tell who the clients are. “unix” being one of these modules (the weakest one). There are many others like “sss”, kerberos, GSI, etc. With XrootdFS, it may run as a user (lets say user “abc”) that have access all access privileges to the Xrootd cluster. So when you do a “rm” via XrootdFS, Xrootd cluster see user “abc” deleting the file. This probably explain what you see. This behavior can be change if you use XrootdFS with the “sss” security module (and use a special type of “sss” key, see the xrootdfs man page). Your commnets on XrdCNSd is correct. That was one of the initial intends. This function (you mentioned) can _mostly_ be archived by using oss.space setup in the xrootd cluster configuration. There are pros and cons in either way. In my view XrdCNSd is better than using oss.space. XrdCNSd is also reliable. But it is an extra service that I don’t need. regards, -- Wei Yang | [log in to unmask] | 650-926-3338(O) On 4/6/18, 1:55 AM, "[log in to unmask] on behalf of Heiko Schröter" <[log in to unmask] on behalf of [log in to unmask]> wrote: >Am 06.04.2018 um 10:35 schrieb Yang, Wei: >> It is a bit surprise. Here is what I have: >> >> xrootd.seclib /usr/lib64/libXrdSec.so >> sec.protocol /usr/lib64 unix >> acc.authdb $(scriptspath)/auth_file >> acc.authrefresh 300 >> ofs.authorize >> >> >> and with your AuthFile >> >> u * /xrootd lr >> u root /xrootd a >> >> Everyone (every remote user) should be able to read from /xrootd and only (remote) root can read-write. BTW, Xrootd use access control list. The above AuthFile reflect ACL rules. > >Update: This seems works with the xrootd tools i.e.: > >schroete@pc1 # xrdfs REDIRECTOR chmod /xrootd/myTestDir/willi "rwxrwxrwx" >[ERROR] Server responded with an error: [3010] Unable to chmod >/xrootd/myTestDir/willi; permission denied > >But using the xrootd fuse mount i'am able to create/delete files in >/xrootd as everyone. > >/etc/fstab: >xrootdfs /mnt/xrootd fuse >rdr=xroot://REDIRECTOR:1094//xrootd/,fsname=xrootdfs,max_write=131072,attr_timeout=10,entry_timeout=10,rw,noatime >0 0 > >cd /mnt/xrootd; echo "laura" > willi; rm willi --> no error > >Is this intended with the FUSE module ? > > >> >> The CNSd (composed name space, along with ofs.forward) is essentially a DB of what files are in an xrootd storage cluster. >As far as i understood the docs it might be used as an inventory in case >of a desaster loss of an raid system. So we would have at least an index >of the files. This is very good to have for us. > > > >Regards >Heiko > >> >> -----Original Message----- >> From: <[log in to unmask]> on behalf of Heiko Schröter <[log in to unmask]> >> Date: Friday, April 6, 2018 at 1:11 AM >> To: xrootd-l <[log in to unmask]> >> Subject: Re: read write permissions >> >>> Hello, >>> >>>>> --> sec.protocol /usr/lib/xrootd unix >>>> This is wrong. It should be something like: >>>> >>>> xrootd.seclib /usr/lib64/libXrdSec.so >>>> sec.protocol /usr/lib64 unix >>> Tried it, but it does not change a thing. Any user has r/w access to the >>> file system. >>> So i it would be nice when there would be a pointer to some docs or such >>> how i can achieve the r/w permissions. >>> I don't get it how xrootd decides between access to the "storage pool", >>> or access permissions for a file/directory. >>> >>>> Also, I am curious, we used the following lines a long time ago but stopped using since. Are you sure you need them? >>>>> ofs.notify closew create mkdir mv rm rmdir trunc | >>>>> /usr/bin/XrdCnsd -d -D 2 -i 90 -b $(xrdr):1095:$(inventory) >>>>> ofs.notifymsg create $TID create $FMODE $LFN?$CGI >>>>> ofs.notifymsg closew $TID closew $LFN $FSIZE >>> I got this from a tutorial for setting up an Inventory. The inventory >>> works. But i have to admit that i don't fully understand all the bits >>> and pieces in the docs. >>> >>> Heiko >>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-L list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-L list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >> > >-- >----------------------------------------------------------------------- >Dipl.-Ing. Heiko Schröter >Institute of Environmental Physics (IUP) phone: ++49-(0)421-218-62092 >Institute of Remote Sensing (IFE) fax: ++49-(0)421-218-62070 >University of Bremen (FB1) >P.O. Box 330440 email: [log in to unmask] >Otto-Hahn-Allee 1 >28359 Bremen >Germany >----------------------------------------------------------------------- > >######################################################################## >Use REPLY-ALL to reply to list > >To unsubscribe from the XROOTD-L list, click the following link: >https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1