 |
 |
Hi Heiko, I understand this problem, and I donıt know if this problem has been resolved or not. You probably donıt even need xrootdfs to create this problem. I will check with Andy next week. Also note that the ³sss² key to be used between xrootdfs and xrootd servers is quite special (see xrootdfs man page). At the xrootdfs side, the keytab has to be created for user "anybody" and group "usrgroup", and can not have any other user/group. At the xrootd servers side, the keytab should also have this key but can have other keys as well. regards, -- Wei Yang | [log in to unmask] | 650-926-3338(O) -----Original Message----- From: Heiko Schröter <[log in to unmask]> Date: Saturday, April 28, 2018 at 12:11 AM To: Wei Yang <[log in to unmask]>, xrootd-l <[log in to unmask]> Cc: "[log in to unmask]" <[log in to unmask]> Subject: Re: xrootd 4.8.3-rc1 FUSE mount "eligible servers shunned" >We have created a xrootd storage system with one redirector and 12 data >server. In our institut anyone needs at least read access to this system >of satellite data. >To protect users and the admins the FUSE mount shall be ro only because >any user could use this interface on his local machine. > >Therefore we do use UNIX auth and it does what we had in mind. The users >are recognized via ldap and can write (xrdcp et al, not FUSE cp) into >their dirs which are enabled in the Authfile. > > >Our Test Authfile: >u * /xrootd lr >u root /xrootd lr >u schroete /xrootd/schroete a >u vountas /xrootd/vountas a >u schell /xrootd/schell a >u bram /xrootd/bram a > >The Test Xrootd.cf: >xrd.timeout hail 30 idle 0 kill 3 read 5 >all.export /xrootd >set xrdr=RDIRECTOR >set inventory=/var/log/xrootd/inventory >all.manager $(xrdr):3121 >cms.allow host *.our.domain > >if $(xrdr) && named cns > all.export $(inventory) > xrd.port 1095 >else if $(xrdr) > all.role manager > oss.defaults rw > xrd.port 1094 >else > all.role server > 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 > xrootd.seclib /usr/lib/libXrdSec.so > # sec.protocol /usr/lib sss -s /etc/xrootd/sss.keytab > sec.protocol /usr/lib unix > acc.authdb /etc/xrootd/Authfile > acc.authrefresh 60 > ofs.authorize > cms.space min 100g 110g >fi > > >The FUSE mount on our number cruncher(s) is done via autofs. This is >what most users would also use on their machines or a fixed mount in fstab. > >What happens if user "schroete" is trying to copy a file via the FUSE >mount into "/xrootd/schroete": > >1) schroete@client1 # cp foo.txt /mnt/xrootd/schroete/foof.txt -> >Permission denied, ok. (No user shall have write access via FUSE) > >2) schroete@client1 # xrdfs REDIRECTOR rm /mnt/xrootd/bram/foof.txt -> >eligible server shunned > >The filename "foo.txt" is blocked for any further operation. xrootd >claims "file exist". But this is only inside the xrootd deamons. There >exisists no file on the data servers. > >I just rechecked it with the SSS option enabled and this Test sss.keytab >but to no avail. > >0 u:vountas g:users n:nowhere N:6549388083412860932 c:1524898243 e:0 f:0 >k:9247585b2e1153a73b83c09c17afeb3cca432a12e3ef465634eed3e2c37f1800 >0 u:schroete g:users n:nowhere N:6549387937383972866 c:1524898209 e:0 >f:0 k:9fe81373b803b3ebf86c6074a4d921703802fcd5a51030f5b95f87f7e97a9e06 >0 u:xrootd g:nogroup n:nowhere N:6549040822422077441 c:1524817390 e:0 >f:0 k:12f2a7a111e4e27204224a7521a85ab3d2435d88d57a4b62a10bbd3a8b3a32c0 >0 u:bram g:users n:nowhere N:6549388053348089859 c:1524898236 e:0 f:0 >k:e621083a0c29307de036dbf59a9adfa2cb40a2fde382977c2fbf99e696e63729 >0 u:schell g:users n:nowhere N:6549388113477632005 c:1524898250 e:0 f:0 >k:d57d9106ad63c98eac319ab0e7515a805041bdc6a655c7c85afce37270ac74c6 > > >Best >Heiko > > >Am 27.04.2018 um 19:51 schrieb Yang, Wei: >> I am still not sure I fully understand the issue so bear with me if I am wrong: >> >> for xrootdfs, "sss" is optional. Without sss, the xrootdfs will access data in the xrootd cluster as the uid that runs xrootdfs, not the user that access through xrootdfs. With "sss" correctly setup (on both xrootdfs and xrootd cluster), xrootd cluster "sees" the actual user. >> >> If you configure your xrootd cluster to support both "sss" and "unix", then those users who don't have the "sss" key will access the xrootd cluster using "unix". So they can still read/write if you permit so (it is just not really secure). >> >> -- >> Wei Yang | [log in to unmask] | 650-926-3338 ######################################################################## 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