[LU-5074] Connection flag reservation for Secure Data Appliance

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.5.2
• Type: Improvement
• Priority: Minor
• Reporter: Andrew Perepechko
• Assignee: Peter Jones
• Resolution: Won't Fix
• Labels: patch

Description

We need to reserve a connection flag for the Secure Data Appliance.

A patch will be uploaded shortly.

Thanks.

Issue Links

• is related to: LU-6784 Defects in SELinux support

Comments

[Andrew Perepechko]

http://review.whamcloud.com/#/c/10352/

[Christopher Morrone]

Can you point us to the design document for the new protocol referenced in the patch?

Can you explain what the Secure Data Appliance is and what new Lustre protocol(s) it will require?

[Andrew Perepechko]

Christopher, you can find additional information at http://www.xyratex.com/products/clusterstor-sda

I'm afraid I'm not entitled to expose any internal documents or the code. The wire protocol changes
mentioned in the patch include additional security data transfered between SDA-aware clients and servers.

[Andreas Dilger]

The code will eventually need to be released as part of a GPL module in the kernel.

On a technical front, it will be interesting to see how this resolves the issue of trusting Lustre clients. Is it implementing Kerberos and OST capabilities, or some other mechanism?

[Christopher Morrone]

I'm afraid that if you can't tell us anything about the protocol changes, then we can't support it in the community, Open Source version of Lustre. If you decide to make private, proprietary changes to Lustre, then the burden is entirely on you to deal with the continued maintenance implications.

[Nathan Rutman]

Protocol changes include the transport of additional MLS information to/from SE Linux clients, and some additional RPCs between servers. We're in a bit of a conundrum because the security accreditation we're under does not allow us to share the code, even though of course it based on Lustre which they understand is Open Source. So while are trying to figure out legally how we can do this, in the meantime to let our customers connect to our SDA version and to regular Lustre systems without conflict, we thought pushing a connect flag upstream would be the easiest and least contentious option.

[Nathan Rutman]

(There are of course plenty of precedents for this; the Linux kernel has all sorts of reserved flags for proprietary drivers.)

[Christopher Morrone]

That would certainly seem to be a troubling situation, but one that was self-inflicted. If your organization has chosen to violate Lustre's license, I'm not sure why the community should assist you in doing so.

[Christopher Morrone]

(There are of course plenty of precedents for this; the Linux kernel has all sorts of reserved flags for proprietary drivers.)

Yes, but those are generally for things like ioctl numbers, and Linus has more-or-less taken the stance that kernel modules are not a derivative product of the kernel, and proprietary code is allowed. So avoiding ioctl conflict makes some sense in that situation.

Lustre grants no such latitude for derivative products.

[Nathan Rutman]

It's just a flag, and it just as sensibly is reasonable to avoid conflicts with different versions.

[Christopher Morrone]

It is not just a flag; it is condoning the violation of Lustre's license. If the "different version" were to be made Free Software (Open Source), compatible with Lustre's license, and implemented in a way that could be integrated in to Lustre, then I would withdraw my objection.

Letting this one little flag into Lustre introduces a new Lustre precedence that is not good for the Lustre Free Software/Open Source community.

Would you like me to put this on the CDWG's agenda for discussion on May 21?

[Nathan Rutman]

I am not going to argue about licensing issues here; I will have to discuss with my management how to proceed.

[Peter Jones]

No longer relevant