On Thu, May 8, 2014 at 12:20 PM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote:
> They were: a) snap view generation requires privileged ops to
> glusterd. So moving this task to the server side solves a lot of thoseNot really. A server-side component issuing privileged requests
> challenges.
whenever a client asks it to is no more secure than a client-side
component issuing them directly.
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.
There needs to be some sort of
authentication and authorization at the glusterd level (the only place
these all converge). This is a more general problem that we've had with
glusterd for a long time. If security is a sincere concern for USS,
shouldn't we address it by trying to move the general solution forward?
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.
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
