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
|