Print

Print


OK, the sad story is the way we are approaching this is forbidden in the XRootD framework

Yes - this is what I was suspecting as I was looking at the potential XrdSecEntity object lifetime issues.

Then I can pass a stripped down version of the SecEntity object with that uid/gid in it so you can use it for setfsuid/fsgid.

If we are going to be serializing the uid/gid portions of the SecEntity, what's the added cost to serialize the whole thing (or at least make a copy of it)? Doesn't SSS have to do something similar? I'd be surprised if there was no serialization code existing already for the XrdSecEntity that can be used to pass data to the background task.

(btw those are deprecated now so they may not be there in the future).

They were marked as deprecated in 2013 because of changes to signal handling in Linux 2.0 (1996). However, while the original use case is now obsolete, I see no replacement option for having a per-thread FS ID and it being a valid use case. Given there's no other alternate and Linux's history of carrying these forward forever ... I'm not too worried.


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/pull/1319#issuecomment-721159545", "url": "https://github.com/xrootd/xrootd/pull/1319#issuecomment-721159545", "name": "View Pull Request" }, "description": "View this Pull Request 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