 |
 |
Hi Andy, Brian, > -----Original Message----- From: Brian Bockelman > Sent: Tuesday, July 03, 2018 8:29 AM > To: Fabrizio Furano >> I would personally fix SecEntity with no mercy, as even now there are >> so many cases >> of abuse of its fields, just to carry around information of some kind. >> A striking >> example is that the user DN is kept in a "moninfo" field. There are >> others. >> (and IMO the only way to clean it is to rename all of them, no mercy) > >>> Yes, this definitely should be cleaned up! That's separate from >>> whether it has to be cleaned up to better support tokens though... > Please recommend the additional fields you would like to see. Using > field not intended for their purpose is not sustainable. You will > constantly be fixing your plugins if you go that route. I already have > uid/gid and a TLS usage flag in mind. I also see you will want the > protocol being used as another one. > I would start from the obvious ones, with fields having easily recognizable names, e.g. : - DN, or identity of the client that connected - groups/FQANs of the client that connected. Must be an array of some kind... - DN, or identity of the user that the client is possibly acting on behalf of - groups/FQANs of the user that the clientis possibly acting on behalf of. Must be an array of some kind... - protocol ID (a string?), e.g. 'xrootd' or 'http/https' >>> But again, this is a question about whether SecEntity is about the >>> session or the request. > The SecEntity is about the session. Unfortunately, HTTP/S does not have > sessions making the bridging a bit problematic and usually expensive. > That said, one should explore faking a session using cookies or whatever > to get the overhead down to a reasonable level. > IMO SecEntity is about the connection, a session is a more high-level entity which in some cases may be the same >> I don't think I would like to see request information inside >> SecEntity. xrootd already has >> a data structure modelling requests. It should be there. > Fabrizio, what structure are you think about? Is that the XrdOucEnv > which is request specific? > For example XrdHTTP has XrdHTTPReq, which I found extremely comfortable to use. Pass it as a reference and the function has everything it needs to process a request. The xrootd protocol instead has the ClientRequest union, which is a bit more low level. The top IMO would be to have a request class that contains at least ClientRequest and SecEntity, and is able to accommodate commonly used fields coming from preprocessing of these. >> Is there a way to put security information into the request structure >> (the XrdOucEnv -- does it have its own XrdSecEntity)? I worry about >> overloading the >semantics of arbitrary key-value pairs with security >> data. > Indeed you should worry and a lot. it's awfully expensive when you run > amuck constructing key/value tables on a request basis. The XrdOucEnv > structure is usually (always for an actual user request) associated with > the SecEntity structure. So, the request is presented in the context of > a session. That is done in the OFS layer as the protocol driver simply > asserts an operation passing the session information, the request data > and metadata as separate items. The OFS combines the metadata and > session information onto an "environment" for the request data. > I agree on the cost of keyvalue pairs. Common fields should be fast to retrieve. At the same time in the xrootd ecosystem of plugins there are several examples that are slower, forcing the code to parse very long opaque strings. Not a good reason to give up organising things, however. Fabrizio > Andy > > ######################################################################## > 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 ######################################################################## 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