Hi, On Mon, Mar 6, 2023 at 3:24 AM Gert Doering <g...@greenie.muc.de> wrote:
> Hi, > > On Mon, Mar 06, 2023 at 12:33:46AM -0500, selva.n...@gmail.com wrote: > > From: Selva Nair <selva.n...@gmail.com> > > > > - When management-client-group is in use, allow access if any of > > the supplementary groups of the user matches the specified group. > > > > Currently only the effective gid of the peer socket is checked > > which is normally the primary group of user. As unprivileged users > > have no easy way of changing the effective gid of a process, > > group based access control is of very limited use without this change. > > I'm not really convinced this is a good way forward - it's yet another > extra function for a very niche use case, as in "the code has been like > this for 100 years, and nobody has ever used it". > > What you do is also not exactly "the user connecting has this gid at the > time of connection" but "the uid reported by getpeerid() has this group > listed in /etc/groups", which will be the same in many cases, but is > still checking something different. > I was of the same opinion when I first saw issue #264, but I think the original intent of "--management-client-group has to be what I've implemented or something similar. Docs refer to it as group (not effective gid of the socket), and restricting based on gid reported by getpeerid is kind of useless. Why use "group" if it can't be used to restrict access to a set of users using a supplementary group... I would propose to extend the documentation with "this only checks the > primary gid at time of connection, if this does not work for your use > case, put the socket into a directory with the right gid and mode 750 > and do not use that openvpn option" - as you wrote in the github ticket. > It's impossible to save that option by documenting. In that case, let's just make it a no-op and document that this option has no effect. And suggest the above for how to achieve group-based access control.. > > - Also accept if uid = 0 irrespective of the group. > > This part is fine for me, as it follows the traditional unix way of > "root may pass". > I'm not keen on touching some code and ignore that a closely related code stays crippled (IMO). Unless we can make --management-client-group a no-op as mentioned above. As you say this is an obscure option -- we can leave it "as is". Selva
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
