<font size=2 face="sans-serif">HI Aaron, </font><br><font size=2 face="sans-serif">not sure, if we are ready to talk/ distribute
pnfs4.1 experiences here.. </font><br><font size=2 face="sans-serif">I know one customer doing pNFS and for
myself , we did a lot of testing here</font><br><font size=2 face="sans-serif">please contact me directly .. let's
see, how I can help .. </font><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Aaron Knister <aaron.s.knister@nasa.gov></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif"><gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/08/2017 11:14 PM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
multicluster security</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><font size=3>Interesting! Thank you for the explanation.</font><p><font size=3>This makes me wish GPFS had a client access model that
more closely mimicked parallel NAS, specifically for this reason. That
then got me wondering about pNFS support. I've not been able to find much
about that but in theory Ganesha supports pNFS. Does anyone know of successful
pNFS testing with GPFS and if so how one would set up such a thing?</font><p><font size=3>-Aaron</font><p><font size=3>On 08/25/2017 06:41 PM, IBM Spectrum Scale wrote:</font><p><font size=2>Hi Aaron,</font><font size=3><br></font><font size=2><br>If cluster A uses the mmauth command to grant a file system read-only access
to a remote cluster B, nodes on cluster B can only mount that file system
with read-only access. But the only checking being done at the RPC level
is the TLS authentication. This should prevent non-root users from initiating
RPCs, since TLS authentication requires access to the local cluster's private
key. However, a root user on cluster B, having access to cluster B's private
key, might be able to craft RPCs that may allow one to work around the
checks which are implemented at the file system level.</font><font size=3><br></font><font size=2><br>Regards, The Spectrum Scale (GPFS) team<br><br>------------------------------------------------------------------------------------------------------------------<br>If you feel that your question can benefit other users of Spectrum Scale
(GPFS), then please post it to the public IBM developerWroks Forum at </font><a href="https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000000479"><font size=2 color=blue><u>https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000000479</u></font></a><font size=2>.
<br><br>If your query concerns a potential software error in Spectrum Scale (GPFS)
and you have an IBM software maintenance contract please contact 1-800-237-5511
in the United States or your local IBM Service Center in other countries.
<br><br>The forum is informally monitored as time permits and should not be used
for priority messages to the Spectrum Scale (GPFS) team.</font><font size=3><br><br></font><img src=cid:_1_D963B69CD963A9C4002BC288C1258196 alt="Inactive
hide details for Aaron Knister ---08/21/2017 11:04:06 PM---Hi
Everyone, I have a theoretical question about GPFS multi" style="border:0px solid;"><font size=2 color=#424282>Aaron
Knister ---08/21/2017 11:04:06 PM---Hi Everyone, I have a theoretical question
about GPFS multiclusters and security.</font><font size=3><br></font><font size=2 color=#5f5f5f><br>From: </font><font size=2>Aaron Knister </font><a href=mailto:aaron.s.knister@nasa.gov><font size=2 color=blue><u><aaron.s.knister@nasa.gov></u></font></a><font size=2 color=#5f5f5f><br>To: </font><font size=2>gpfsug main discussion list </font><a href="mailto:gpfsug-discuss@spectrumscale.org"><font size=2 color=blue><u><gpfsug-discuss@spectrumscale.org></u></font></a><font size=2 color=#5f5f5f><br>Date: </font><font size=2>08/21/2017 11:04 PM</font><font size=2 color=#5f5f5f><br>Subject: </font><font size=2>[gpfsug-discuss] multicluster security</font><font size=2 color=#5f5f5f><br>Sent by: </font><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org"><font size=2 color=blue><u>gpfsug-discuss-bounces@spectrumscale.org</u></font></a><p><hr noshade><font size=3><br><br></font><tt><font size=2><br>Hi Everyone,<br><br>I have a theoretical question about GPFS multiclusters and security. <br>Let's say I have clusters A and B. Cluster A is exporting a filesystem
<br>as read-only to cluster B.<br><br>Where does the authorization burden lay? Meaning, does the security rely
<br>on mmfsd in cluster B to behave itself and enforce the conditions of the
<br>multi-cluster export? Could someone using the credentials on a <br>compromised node in cluster B just start sending arbitrary nsd <br>read/write commands to the nsds from cluster A (or something along those
<br>lines)? Do the NSD servers in cluster A do any sort of sanity or <br>security checking on the I/O requests coming from cluster B to the NSDs
<br>they're serving to exported filesystems?<br><br>I imagine any enforcement would go out the window with shared disks in
a <br>multi-cluster environment since a compromised node could just "dd"
over <br>the LUNs.<br><br>Thanks!<br><br>-Aaron<br><br>-- <br>Aaron Knister<br>NASA Center for Climate Simulation (Code 606.2)<br>Goddard Space Flight Center<br>(301) 286-2776<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org</font></tt><tt><font size=2 color=blue><u><br></u></font></tt><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=IbxtjdkPAM2Sbon4Lbbi4w&m=oK_bEPbjuD7j6qLTHbe7HM4ujUlpcNYtX3tMW2QC7_w&s=BliMQ0pToLIIiO1jfyUp2Q3icewcONrcmHpsIj_hMtY&e="><tt><font size=2 color=blue><u>https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=IbxtjdkPAM2Sbon4Lbbi4w&m=oK_bEPbjuD7j6qLTHbe7HM4ujUlpcNYtX3tMW2QC7_w&s=BliMQ0pToLIIiO1jfyUp2Q3icewcONrcmHpsIj_hMtY&e=</u></font></tt></a><tt><font size=2> <br></font></tt><font size=3><br><br><br><br><br></font><br><tt><font size=3>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=3 color=blue><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></tt></a><tt><font size=3><br></font></tt><br><tt><font size=2>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br></font></tt><br><br><BR>