 |
 |
Hmm, Brian musty have used a different mailer as the email text got scrunched into an attached text file. Bad Brian! Anyway.... -----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. >>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. > 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? >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. 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