 |
 |
so ok, all seems fine at the moment: for a denied access I now get 130211 09:58:43 17677 secgsiVOMS_Fun: proxy: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Stefano Perazzini/CN=proxy 130211 09:58:43 17677 secgsiVOMS_Fun: adding cert: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Stefano Perazzini 130211 09:58:43 17677 secgsiVOMS_Fun: retrieval successful 130211 09:58:43 17677 secgsiVOMS_Fun: found VO: lhcb 130211 09:58:43 17677 secgsiVOMS_Fun: VOMS extensions do not match required criteria (grpopt=0;grps=/cms;vos=cms) 130211 09:58:43 17677 secgsi_Authenticate: ERROR: the VOMS extraction plug-in reported a failure for this handshake 130211 09:58:43 17677 XrootdXeq: User authentication failed; 130211 09:58:43 17677 perazzin.2012:[log in to unmask] XrootdResponse: 0100 sending err 3010: 130211 09:58:43 17677 perazzin.2012:[log in to unmask] XrootdProtocol: 0100 req=3010 dlen=160 130211 09:58:43 17677 perazzin.2012:[log in to unmask] XrootdResponse: 0100 sending err 3006: Invalid request; user not authenticated which is fine I checked I can still open the file with my cms proxy ;) On Feb 9, 2013, at 1:43 PM, Tommaso Boccali <[log in to unmask]> wrote: > ciao gerri, thanks for the explanation, I will test on monday since a need a !cms around > > tom > On Feb 8, 2013, at 18:34 , Gerardo Ganis <[log in to unmask]> wrote: > >> >> Hi, >> >> The point is that by default VOMS attributes are not required, so a failure of he extraction step >> does not imply a authentication failure. >> Can you try adding '-vomsat:2' in the sec.protocol gsi directive ? >> >> Gerri >> >> On 2/8/13 6:25 PM, Tommaso Boccali wrote: >>> uhm, but this could work for me also >>> >>> I will try in the week end and report back ;) >>> >>> tom >>> On Feb 8, 2013, at 18:19 , "Yang, Wei" <[log in to unmask]> wrote: >>> >>>> I guess you are right. Since I have (and only have) 'g /atlas /path rl' in oss.authdb file. Users that doesn't have group '/atlas' filled in XrdSecEntity.grps will be rejected. >>>> >>>> regards, >>>> Wei Yang | [log in to unmask] | 650-926-3338(O) >>>> >>>> >>>> >>>> >>>> On Feb 8, 2013, at 1:19 AM, Tommaso Boccali wrote: >>>> >>>>> wait, but here i think the filesystem rejects you, not the plugin (FS says permission denied) is it correct? In our case we would like Xrootd to say no-go (based on VOMS) before even attempting the file::Open >>>>> >>>>> my impression from this log is instead that the plugin said "please go ahead" >>>>> >>>>> >>>>> tom >>>>> >>>>> On Feb 7, 2013, at 11:02 PM, "Yang, Wei" <[log in to unmask]> wrote: >>>>> >>>>>> I am an atlas user. I have this config >>>>>> >>>>>> -vomsfunparms:certfmt=raw|dbg|vos=cms|grps=/atlas >>>>>> >>>>>> and it correctly rejected me: >>>>>> >>>>>> 130207 13:57:32 6683 secgsiVOMS_Fun: proxy: /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203/CN=proxy >>>>>> 130207 13:57:32 6683 secgsiVOMS_Fun: adding cert: /DC=org/DC=doegrids/OU=People/CN=Wei Yang 74203 >>>>>> 130207 13:57:32 6683 secgsiVOMS_Fun: retrieval successful >>>>>> 130207 13:57:32 6683 secgsiVOMS_Fun: found VO: atlas >>>>>> 130207 13:57:32 6683 secgsiVOMS_Fun: VOMS extensions do not match required criteria (/atlas;vos=cms) >>>>>> 130207 13:57:32 6683 XrootdXeq: yangw.17099:8@atlint01 login as 684536c7.0 >>>>>> 130207 13:57:32 6683 ofs_open: yangw.17099:8@atlint01 Unable to open /atlas/dq2/user/HironoriIto/user.HironoriIto.xrootd.wt2/user.HironoriIto.xrootd.wt2-100M; Permission denied >>>>>> >>>>>> it allows me to connect but ultimately I am rejected because the oss.authdb has "g /atlas /path rl". This is the version before Gerri's fix of the uninitialized string, and it is slc5-gcc4.1. >>>>>> >>>>>> regards, >>>>>> Wei Yang | [log in to unmask] | 650-926-3338(O) >>>>>> >>>>>> >>>>>> On Feb 7, 2013, at 2:12 AM, Tommaso Boccali wrote: >>>>>> >>>>>>> too optimistic unfortunately: an atlas user is allowed >>>>>>> >>>>>>> 130207 11:09:51 5718 stupputi.6186:[log in to unmask] XrootdProtocol: 0100 req=3000 dlen=5877 >>>>>>> 130207 11:09:51 5718 secgsi_Authenticate: WARNING: user mapping lookup ok, but the requested user is not authorized (stupputi). Instead, mapped as .atlas. >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: proxy: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Salvatore Alessandro Tupputi/CN=proxy >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: adding cert: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Salvatore Alessandro Tupputi >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: retrieval successful >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: found VO: atlas >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> group: '/atlas', role: 'NULL', cap: 'NULL' >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> group: '/atlas/it', role: 'NULL', cap: 'NULL' >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> group: '/atlas/lcg1', role: 'NULL', cap: 'NULL' >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> fqan: '/atlas/Role=NULL/Capability=NULL' >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> fqan: '/atlas/it/Role=NULL/Capability=NULL' >>>>>>> 130207 11:09:51 5718 secgsiVOMS_Fun: ---> fqan: '/atlas/lcg1/Role=NULL/Capability=NULL' >>>>>>> 130207 11:09:51 5718 stupputi.6186:[log in to unmask] XrootdResponse: 0100 sending OK >>>>>>> 130207 11:09:51 5718 XrootdMonitor: 196 bytes sent to xrootd.t2.ucsd.edu:9930 rc=0 >>>>>>> 130207 11:09:51 5718 XrootdXeq: stupputi.6186:[log in to unmask] login as .atlas >>>>>>> >>>>>>> any idea why is wrong? >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> tom >>>>>>> >>>>>>> >>>>>>> On Feb 7, 2013, at 11:10 , Tommaso Boccali <[log in to unmask]> wrote: >>>>>>> >>>>>>>> and non cms user gets >>>>>>>> >>>>>>>> 130207 11:01:43 5718 XrdSched: scheduling monitor window clock in 5 seconds >>>>>>>> 130207 11:01:43 5846 tentiams.685:[log in to unmask] XrootdProtocol: 0100 req=3000 dlen=5349 >>>>>>>> 130207 11:01:43 5846 secgsi_Authenticate: WARNING: user mapping lookup ok, but the requested user is not authorized (tentiams). Instead, mapped as .dteam. >>>>>>>> 130207 11:01:43 5846 secgsiVOMS_Fun: proxy: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Matteo Tenti/CN=proxy >>>>>>>> 130207 11:01:43 5846 secgsiVOMS_Fun: adding cert: /C=IT/O=INFN/OU=Personal Certificate/L=CNAF/CN=Matteo Tenti >>>>>>>> 130207 11:01:43 5846 secgsiVOMS_Fun: retrieval FAILED: Cannot verify AC signature! >>>>>>>> 130207 11:01:43 5846 secgsi_Authenticate: ERROR: the VOMS extraction plug-in reported a failure for this handshake >>>>>>>> 130207 11:01:43 5846 XrootdXeq: User authentication failed; >>>>>>>> 130207 11:01:43 5846 tentiams.685:[log in to unmask] XrootdResponse: 0100 sending err 3010: >>>>>>>> 130207 11:01:43 4964 XrdInet: Accepted connection from [log in to unmask] >>>>>>>> >>>>>>>> if this is what is expected, we are good to go >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>> On Feb 7, 2013, at 10:12 , Tommaso Boccali <[log in to unmask]> wrote: >>>>>>>> >>>>>>>>> ciao gerri, for the moment I have the _impression_ it is working: >>>>>>>>> >>>>>>>>> 130207 10:08:18 4968 XrdSched: scheduling stats reporter in 30 seconds >>>>>>>>> 130207 10:08:19 4964 XrdInet: Accepted connection from [log in to unmask] >>>>>>>>> 130207 10:08:19 4967 XrdSched: running ?:8@so1wn60 inq=0 >>>>>>>>> 130207 10:08:19 4967 XrdProtocol: matched protocol xrootd >>>>>>>>> 130207 10:08:19 4967 ?:8@so1wn60 XrdPoll: FD 8 attached to poller 0; num=1 >>>>>>>>> 130207 10:08:19 4967 ?:8@so1wn60 XrootdProtocol: 0100 req=3007 dlen=0 >>>>>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdResponse: 0100 sending 50 data bytes; status=0 >>>>>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdProtocol: 0100 req=3000 dlen=101 >>>>>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdProtocol: 0100 more auth requested; sz=1837 >>>>>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdResponse: 0100 sending 1837 data bytes; status=4002 >>>>>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdProtocol: 0100 req=3000 dlen=15253 >>>>>>>>> 130207 10:08:19 4967 secgsi_Authenticate: WARNING: user mapping lookup ok, but the requested user is not authorized (cmsprd). Instead, mapped as cmssgm. >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: proxy: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy/CN=proxy/CN=pro >>>>>>>>> xy/CN=proxy/CN=limited proxy >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy/CN=proxy >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy/CN=proxy/ >>>>>>>>> CN=proxy >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=asciaba/CN=430796/CN=Andrea Sciaba/CN=proxy/CN=proxy/CN=proxy/CN=proxy/ >>>>>>>>> CN=proxy/CN=proxy >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: retrieval successful >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: found VO: cms >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> group: '/cms', role: 'production', cap: 'NULL' >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> group: '/cms', role: 'NULL', cap: 'NULL' >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> group: '/cms/TEAM', role: 'NULL', cap: 'NULL' >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> group: '/cms/dbs', role: 'NULL', cap: 'NULL' >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> fqan: '/cms/Role=production/Capability=NULL' >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> fqan: '/cms/Role=NULL/Capability=NULL' >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> fqan: '/cms/TEAM/Role=NULL/Capability=NULL' >>>>>>>>> 130207 10:08:19 4967 secgsiVOMS_Fun: ---> fqan: '/cms/dbs/Role=NULL/Capability=NULL' >>>>>>>>> 130207 10:08:19 4967 cmsprd.26556:8@so1wn60 XrootdResponse: 0100 sending OK >>>>>>>>> >>>>>>>>> >>>>>>>>> is this what you would expect? >>>>>>>>> >>>>>>>>> config is as simple as >>>>>>>>> >>>>>>>>> sec.protparm gsi -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:grpopt=0|vos=cms|certfmt=raw >>>>>>>>> sec.protocol /usr/lib64 gsi -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/xrd/hostcert.pem -key:/etc/grid-security/xrd/hostkey.pem -crl:3 -moninfo >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 7, 2013, at 10:00 , Tommaso Boccali <[log in to unmask]> wrote: >>>>>>>>> >>>>>>>>>> ok thanks, will do >>>>>>>>>> because I found out voms 2.0.8 requires a change EMI1->EMI2 which is not that trivial on a production machine >>>>>>>>>> >>>>>>>>>> tom >>>>>>>>>> On Feb 7, 2013, at 9:58 , Gerardo Ganis <[log in to unmask]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Tom, >>>>>>>>>>> >>>>>>>>>>> My statement 'The builds require VOMS 2.0.8' is probably too strong. The right statement is probably >>>>>>>>>>> 'require VOMS 2.x', so I would give a try with 2.0.7 before bothering finding ways to update ... >>>>>>>>>>> >>>>>>>>>>> Cheers, Gerri >>>>>>>>>>> >>>>>>>>>>> On 2/7/13 9:12 AM, Tommaso Boccali wrote: >>>>>>>>>>>> ciao Gerri, starting to look into this (sorry for the delay) >>>>>>>>>>>> >>>>>>>>>>>> I am stuck at point #1: >>>>>>>>>>>> >>>>>>>>>>>>> 1. The builds require VOMS 2.0.8 which, if I understand correctly, is a not (yet?) available in OSG >>>>>>>>>>>> I have >>>>>>>>>>>> >>>>>>>>>>>> [root@stormgf1 xroot-tests]# rpm -qa|grep voms >>>>>>>>>>>> voms-2.0.7-1.el5.x86_64 >>>>>>>>>>>> >>>>>>>>>>>> So I need to find a way to update this standard way from the repository does not allow me to get a 2.0.8 >>>>>>>>>>>> >>>>>>>>>>>> stay tuned >>>>>>>>>>>> >>>>>>>>>>>> tom >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Feb 4, 2013, at 18:42 , Gerardo Ganis <[log in to unmask]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> This is the status of things: >>>>>>>>>>>>> >>>>>>>>>>>>> The plug-in is available for test at 'https://github.com/gganis/voms.git' from where you can download >>>>>>>>>>>>> the sources. Binaries for SLC5 (x86_64, gcc-4.1, gcc 4.3) and SLC6 (x86_64, gcc-4.6) are available under >>>>>>>>>>>>> >>>>>>>>>>>>> /afs/cern.ch/work/g/ganis/public/vomsxrd/vomsxrd-0.0.1 >>>>>>>>>>>>> >>>>>>>>>>>>> (README and examples under /afs/cern.ch/work/g/ganis/public/vomsxrd). >>>>>>>>>>>>> >>>>>>>>>>>>> With the following caveats: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. The builds require VOMS 2.0.8 which, if I understand correctly, is a not (yet?) available in OSG >>>>>>>>>>>>> 2. Unfortunately the backport of the vomsfun functionality was not complete in the 3.2.x stable branch, >>>>>>>>>>>>> so to use the plug-in you have either to use the HEAD of the 'stable' branch or 3.3.x-rc1 . >>>>>>>>>>>>> RPMs for the stable branch are available from the Teamcity portal: >>>>>>>>>>>>> >>>>>>>>>>>>> https://teamcity-dss.cern.ch:8443/project.html?projectId=project13&tab=projectOverview >>>>>>>>>>>>> >>>>>>>>>>>>> Can you please let me know if you can try this out or what you miss to be able to try? >>>>>>>>>>>>> >>>>>>>>>>>>> Gerri >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 1/31/13 7:19 PM, Yang, Wei wrote: >>>>>>>>>>>>>> I haven't get it to work yet. I am communicating with the developer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> regards, >>>>>>>>>>>>>> Wei Yang | [log in to unmask] | 650-926-3338(O) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Jan 31, 2013, at 2:28 AM, Tommaso Boccali wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Follow-up Comment #2, sr #135141 (project xrootd): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ciao, news on that plugin? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> tom >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________________ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Reply to this item at: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <http://savannah.cern.ch/support/?135141> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Message sent via/by LCG Savannah >>>>>>>>>>>>>>> http://savannah.cern.ch/ >>>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> +--------------------------------------------------------------------------+ >>>>>>>>>>>>> Gerardo GANIS CERN, PH Dept, SFT group, CH 1211 Geneve 23 >>>>>>>>>>>>> room: 32-RC-006, tel: +41 22 7676439 >>>>>>>>>>>>> email: [log in to unmask], fax: +41 22 7669133 >>>>>>>>>>>>> +--------------------------------------------------------------------------+ >>>>>>>>>>>>> >>>> > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1