<div dir="ltr">Luke,<div><br></div><div>Without fully knowing your use case...  If your data partitions so that what cluster B users only need a subset of the file system, such that it doesn't matter if they read anything on it, and the remainder can be kept completely away from them, then a possibility is to have two file systems on cluster A, only one of which is exported to B.  (For example, we have a general user file system going to all clusters, as well as a smaller file system of VM images restricted to hypervisors only.)</div>
<div><br></div><div>The lack of user authentication (such as found in AFS) has handicapped our use of GPFS.  With not completely trusted users (we provide general HPC compute services), someone with a privilege escalation exploit can own the file system, and GPFS provides no defense against this.  I am hoping that maybe native encryption can be bent to provide better protection, but I haven't had opportunity to explore this yet.</div>
<div><br></div><div>/Lindsay<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 14, 2014 at 3:26 AM, Luke Raimbach <span dir="ltr"><<a href="mailto:luke.raimbach@oerc.ox.ac.uk" target="_blank">luke.raimbach@oerc.ox.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear GPFS Experts,<br>
<br>
I have two clusters, A and B where cluster A owns file system GPFS and cluster B owns no file systems.<br>
<br>
Cluster A is mixed Linux/Windows and has IMU keeping consistent UID/GID maps between Windows and Linux environment resulting in a very high ID range (typically both UID/GID starting at 850000000)<br>
<br>
Cluster B remote mounts file system GPFS with UID/GID=0 remapped to 99. This is fine for preventing remote root access to file system GPFS. However, cluster B may have untrusted users who have root privileges on that cluster from time-to-time. Cluster B is "part-managed" by the admin on cluster A, who only provides tools for maintaining a consistent UID space with cluster A.<br>

<br>
In this scenario, what can be done to prevent untrusted root-privileged users on cluster B from creating local users with a UID matching one in cluster A and thus reading their data?<br>
<br>
Ideally, I want to remap all remote UIDs *except* a small subset which I might trust. Any thoughts?<br>
<br>
Cheers,<br>
Luke.<br>
<br>
--<br>
<br>
Luke Raimbach<br>
IT Manager<br>
Oxford e-Research Centre<br>
7 Keble Road,<br>
Oxford,<br>
OX1 3QG<br>
<br>
<a href="tel:%2B44%280%291865%20610639" value="+441865610639">+44(0)1865 610639</a><br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://gpfsug.org" target="_blank">gpfsug.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
</blockquote></div><br></div></div></div>