[ovs-dev] lib: allow group access to Unix domain sockets
diff mbox

Message ID 1444464650-29921-1-git-send-email-azhou@nicira.com
State Superseded
Headers show

Commit Message

Andy Zhou Oct. 10, 2015, 8:10 a.m. UTC
By default, Unix domain sockets are created with file system permission
mode of 0700. Only the process of the belongs to the same user can
access this socket.

For OVS, it may be more convenient to control access at the group
level rather than at the user level, since the process needs to
access OVSDB sockets or daemons' control sockets may not need the
same permission as the OVS daemons.

This patch change Unix domain sockets' file system permission to 0770,
open up the group access.

It has been a issue in the past since OVS, until very recently,
has to run as root. If a process needs to access OVSDB, or OVS daemons'
control sockets, it has to be a root process as well.

With the added --user option to OVS daemons and this change, system
administrators can deploy OVS more securely: OVS daemons can run as
a non root user. Various processes that need to talk to OVS does not
have to root process either.  In fact, they can all run as
different users, as long as they have sufficient rights to access
OVS socket files.

Signed-off-by: Andy Zhou <azhou@nicira.com>
---
 lib/socket-util-unix.c | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Ansis Atteka Nov. 7, 2015, 1:51 a.m. UTC | #1
On 10 October 2015 at 01:10, Andy Zhou <azhou@nicira.com> wrote:

> By default, Unix domain sockets are created with file system permission
> mode of 0700. Only the process of the belongs to the same user can
>
How about:
s/Only the process of the belongs to the same user/This means that only
processes that run under the same user


> access this socket.
>
> For OVS, it may be more convenient to control access at the group
> level rather than at the user level, since the process needs to
>
s/the process needs/other processes need

> access OVSDB sockets or daemons' control sockets may not need the

s/OVSDB sockets or daemons' control sockets.../OVSDB and UNIXCTL sockets
while running under different use.



>

same permission as the OVS daemons.
>
> This patch change Unix domain sockets' file system permission to 0770,
>
s/change/changes

> open up the group access.
>
s/open up the/to grant

>
> It has been a issue in the past since OVS, until very recently,
>
s/has/hasn't

> has to run as root. If a process needs to access OVSDB, or OVS daemons'
>
s/has/had
s/needs/needed


> control sockets, it has to be a root process as well.
>
/s/has to/had to be running under

>
> With the added --user option to OVS daemons and this change, system
> administrators can deploy OVS more securely: OVS daemons can run as
> a non root user. Various processes that need to talk to OVS does not
> have to root process either.  In fact, they can all run as
>
s/root/run a as root or ovs user anymore.

And then next sentence, I believe, becomes optional.

> different users, as long as they have sufficient rights to access
> OVS socket files.
>
> Signed-off-by: Andy Zhou <azhou@nicira.com>
> ---
>  lib/socket-util-unix.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/lib/socket-util-unix.c b/lib/socket-util-unix.c
> index afab195..1453384 100644
> --- a/lib/socket-util-unix.c
> +++ b/lib/socket-util-unix.c
> @@ -349,6 +349,11 @@ make_unix_socket(int style, bool nonblock,
>          }
>          free_sockaddr_un(dirfd, linkname);
>
> +        if (!error) {
> +            /* Allow users with in the same group to connect. */
>
s/with in/within

> +            error = chmod(bind_path, 0770);
>

It seems that bind_unix_socket() called from this same afunction already
calls fchmod. Is there a good reason you have to do one more call from
here? Here is code:

/* Binds Unix domain socket 'fd' to a file with permissions 0700. */
static int
bind_unix_socket(int fd, struct sockaddr *sun, socklen_t sun_len)
{
    const mode_t mode = 0700;
    if (LINUX) {
        if (fchmod(fd, mode)) {


Also, your way, I believe socket is not created with right permissions
atomically.



> +        }
> +
>          if (error) {
>              goto error;
>          }
> --
> 1.9.1
>
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
Andy Zhou Nov. 9, 2015, 6:35 p.m. UTC | #2
On Fri, Nov 6, 2015 at 5:51 PM, Ansis Atteka <ansisatteka@gmail.com> wrote:
>
>
> On 10 October 2015 at 01:10, Andy Zhou <azhou@nicira.com> wrote:
>>
>> By default, Unix domain sockets are created with file system permission
>> mode of 0700. Only the process of the belongs to the same user can
>
> How about:
> s/Only the process of the belongs to the same user/This means that only
> processes that run under the same user
>
>>
>> access this socket.
>>
>> For OVS, it may be more convenient to control access at the group
>> level rather than at the user level, since the process needs to
>
> s/the process needs/other processes need
>>
>> access OVSDB sockets or daemons' control sockets may not need the
>
> s/OVSDB sockets or daemons' control sockets.../OVSDB and UNIXCTL sockets
> while running under different use.
>
>
>>
>>
>>
>> same permission as the OVS daemons.
>>
>> This patch change Unix domain sockets' file system permission to 0770,
>
> s/change/changes
>>
>> open up the group access.
>
> s/open up the/to grant
>>
>>
>> It has been a issue in the past since OVS, until very recently,
>
> s/has/hasn't
>>
>> has to run as root. If a process needs to access OVSDB, or OVS daemons'
>
> s/has/had
> s/needs/needed
>
>>
>> control sockets, it has to be a root process as well.
>
> /s/has to/had to be running under
>>
>>
>> With the added --user option to OVS daemons and this change, system
>> administrators can deploy OVS more securely: OVS daemons can run as
>> a non root user. Various processes that need to talk to OVS does not
>> have to root process either.  In fact, they can all run as
>
> s/root/run a as root or ovs user anymore.
>
> And then next sentence, I believe, becomes optional.
>>
>> different users, as long as they have sufficient rights to access
>> OVS socket files.
>>
>> Signed-off-by: Andy Zhou <azhou@nicira.com>
>> ---
>>  lib/socket-util-unix.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/lib/socket-util-unix.c b/lib/socket-util-unix.c
>> index afab195..1453384 100644
>> --- a/lib/socket-util-unix.c
>> +++ b/lib/socket-util-unix.c
>> @@ -349,6 +349,11 @@ make_unix_socket(int style, bool nonblock,
>>          }
>>          free_sockaddr_un(dirfd, linkname);
>>
>> +        if (!error) {
>> +            /* Allow users with in the same group to connect. */
>
> s/with in/within
>>
>> +            error = chmod(bind_path, 0770);
>
>
> It seems that bind_unix_socket() called from this same afunction already
> calls fchmod. Is there a good reason you have to do one more call from here?
> Here is code:
>
> /* Binds Unix domain socket 'fd' to a file with permissions 0700. */
> static int
> bind_unix_socket(int fd, struct sockaddr *sun, socklen_t sun_len)
> {
>     const mode_t mode = 0700;
>     if (LINUX) {
>         if (fchmod(fd, mode)) {
>
>
> Also, your way, I believe socket is not created with right permissions
> atomically.
>
>
You are right. Changing bind_unix_socket seems to be a better
solution. I will repost with this change.
>>
>> +        }
>> +
>>          if (error) {
>>              goto error;
>>          }
>> --
>> 1.9.1
>>
>> _______________________________________________
>> dev mailing list
>> dev@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>
>

Patch
diff mbox

diff --git a/lib/socket-util-unix.c b/lib/socket-util-unix.c
index afab195..1453384 100644
--- a/lib/socket-util-unix.c
+++ b/lib/socket-util-unix.c
@@ -349,6 +349,11 @@  make_unix_socket(int style, bool nonblock,
         }
         free_sockaddr_un(dirfd, linkname);
 
+        if (!error) {
+            /* Allow users with in the same group to connect. */
+            error = chmod(bind_path, 0770);
+        }
+
         if (error) {
             goto error;
         }