 |
 |
Hi @bbockelm -
It's only software so we have a lot more options than two. I don't mind spending more time to get a consistent understandable implementation, especially when it deals with security. So...
a) The XrdProtocolanon (I made a previous mistake the 'A' letter should be lower case) fits into the scheme. It doesn't require a new client it merely requires that the plugin be available client-side. That may be easy or difficult. I thought that CMS does automatic distribution of various plugins (e.g. StashCache stuff) already so I thought this would just fall into that category. If I'm wrong, then this would be difficult.
b) I take a dim view of hacking the unix protocol. These protocols are supposed to be one-purpose only protocols anything more is just asking for trouble. Sorry if I take the purist approach.
c) One could do something else on the server. Since anon doesn't do anything then the server can do something. Suppose you allowed it to run through the protocols with non succeeding. Then the server could a) simply accept the login without authentication (horror on many faces), or b) redirect the client elsewhere.
Option (b) comes with a lot more flexibility on what to do but I don't see how this is going to solve anything given the case you outlined.
Option (a) is workable but I would insist that if we do that, the server severely restricts what the client can do (e.g. open for reading only, perhaps a stat, read, and close). In fact, I was going to recommend that even with anon protocol (which essentially does the same thing behind the servers back).
At least in (a) we have some modicum of damage control. What do you think?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
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