Hi Oliver,
You are not doing anything wrong per se. You just happen to be the first
one that is actually trying to use the DN for access control and exposed
an inconsistency that has long been forgotten. I say first because this
issue has come up before a long time ago and people have since abondoned
using the DN without, as you point out, also using either gridmap or
LCMAPS to get a resonable "userid". I will look to see where the
inconsistency comes from and let you know what can be done about it.
Andy
On Tue, 4 Aug 2020, Oliver Freyermuth wrote:
> This could also be a configuration issue, if so, please bear with me ;-). I'm using XRootD 5.0.0 in this test (a self-compiled version from master after the `http.tlsreuse` parameter was introduced).
>
> I'm trying to access the path `/data/belle`, given the following configuration (slightly trimmed irrelevant parts):
> ```
> acc.audit deny grant
> acc.authdb /etc/xrootd/auth_file-grid
> acc.authrefresh 60
> all.export /data/belle r/w nostage
> all.manager xrootd-dev.example.com:1213
> all.role server
> all.sitename MYSITE
> cms.allow host xrootd-dev.example.com
> cms.trace all -debug
> http.cadir /etc/grid-security/certificates
> http.desthttps yes
> http.header2cgi Authorization authz
> http.secxtractor /usr/lib64/libXrdVoms.so certfmt=raw|grpopt=useall|vos=atlas,belle,ops,dteam,wlcg|grps=/atlas,/atlas/de,/belle,/ops,/dteam,/wlcg|dbg
> http.selfhttps2http no
> http.tlsreuse on
> if exec xrootd
> xrd.protocol XrdHttp /usr/lib64/libXrdHttp.so
> fi
> sec.protocol /usr/lib64 gsi -dlgpxy:1 -exppxy:=creds -ca:1 -crl:3 -gridmap:/dev/null -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -certdir:/etc/grid-security/certificates -vomsfun:/usr/lib64/libXrdVoms.so -vomsfunparms:certfmt=raw|grpopt=useall|vos=atlas,belle,ops,dteam,wlcg|grps=/atlas,/atlas/de,/belle,/ops,/dteam,/wlcg|dbg
> xrd.port 1094
> xrd.tls /etc/grid-security/hostcert.pem /etc/grid-security/hostkey.pem
> xrd.tlsca certdir /etc/grid-security/certificates
> xrd.trace conn
> xrootd.chksum adler32 crc32 md5
> xrootd.seclib /usr/lib64/libXrdSec.so
> acc.spacechar _
> ```
> with the following `auth_file-grid`:
> ```
> = belleusr o: belle g: /belle
> = bellesadm o: belle g: /belle u: HERES_THE_ID
> x bellesadm /data/belle a
> x belleusr /data/belle lr
> ```
> I am trying with a VOMS proxy with:
> * FQAN `/belle/Role=NULL/Capability=NULL`
> * certificate DN `/C=DE/O=GermanGrid/OU=UniBonn/CN=Oliver Freyermuth`
> * DN hash `aeb776c8.0`
>
> Read access works fine, my problem is granting write access to a single "user" (without using a more elaborate tool such as LCMAPS).
>
> I've tried various IDs for `HERES_THE_ID` with mixed success:
>
> | Value of `HERES_THE_ID` | Write access works via HTTP | Write access works via XRootD |
> |--------------------------------------|-----------------------------------------|-------------------------------------------|
> | /C=DE/O=GermanGrid/OU=UniBonn/CN=Oliver_Freyermuth | denied | denied |
> | Oliver_Freyermuth | denied | denied |
> | aeb776c8.0 | denied | works! |
>
> So I have two issues:
> * Why does the "DN" with escaped space (using `acc.spacechar`, see https://github.com/xrootd/xrootd/issues/712 ) not work?
> * Why does the DN hash only work for a connection from an XRootD client, but not for a connection from a HTTP client?
>
> Note that when creating a connection via `xrdcp`, I see this in the logs:
> ```
> 200804 12:49:14 1255818 XrootdXeq: olifre.1656:33@mytestnode pub IP46 login as aeb776c8.0
> ```
> and when connecting via `curl` using the proxy cert, I see:
> ```
> 200804 12:50:26 1255800 XrootdBridge: eyermuth.3:29@mytestnode login as eyermuth
> ```
> Is it expected that when connecting via HTTP, the connection will not be mapped to an ID containing the certificate DN hash, or did I misconfigure something?
>
> --
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/1268
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/xrootd/xrootd/issues/1268#issuecomment-668781567",
"url": "https://github.com/xrootd/xrootd/issues/1268#issuecomment-668781567",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
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