<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 8, 2014 at 12:20 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">> They were: a) snap view generation requires privileged ops to<br>
</div><div class="">
> glusterd. So moving this task to the server side solves a lot of those<br>
> challenges.<br>
<br>
</div>Not really. A server-side component issuing privileged requests<br>
whenever a client asks it to is no more secure than a client-side<br>
component issuing them directly.</blockquote><div><br></div><div>client cannot ask the server side component to do any privileged requests on its behalf. If it has the right to connect to the volume, then it can issue a readdir() request and get served with whatever is served to it. If it presents an unknown filehandle, snap-view-server returns ESTALE.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> There needs to be some sort of<br>
authentication and authorization at the glusterd level (the only place<br>
these all converge). This is a more general problem that we've had with<br>
glusterd for a long time. If security is a sincere concern for USS,<br>
shouldn't we address it by trying to move the general solution forward?<br>
</blockquote></div><br></div><div class="gmail_extra">The goal was to not make the security problem harder or worse. With this design the privileged operation is still contained within the server side. If clients were to issue RPCs to glusterd (to get list of snaps, their volfiles etc.), it would have been a challenge for the general glusterd security problem.</div>
<div class="gmail_extra"><br></div></div>