Unable to set permissions on the unix socket

[xxorax]

Detailed Description

If you use the unix socket to serve the aptly api (using aptly serve --listen="unix:///var/run/aptly.sock") , you are not able to set the permissions on the socket file.

The file is deleted each time it starts, and recreated (see here), so the permissions are resetted at start.

Using a post command to set the permission on the socket file does not work (with Systemd ExecStartPost=/bin/chmod g+w /var/run/aptly.sock). This is probably because the socket file is deleted asynchronously (after the post command run)

Possible Implementation

I think we just need to not delete the socket file. So an error should be returned if the socket cannot be created, and use it if it already exsits. It should work because the socket is created with the syscall.SO_REUSEADDR option.

By this way, we are able to set the permissions after and it will not reset them when the service start.

Or

Set the permission with the fragment part of the URL unix:///var/run/aptly.sock#660 :)

After the socket file is created:

err := os.Chmod(file, listenURL.Fragment);
if err != nil {
   return fmt.Errorf("unable to serve: %s", err)
}

Your Environment

Debian 9

Thanks !

[smira]

I think we can skip removing file if it exists & it's a socket.

[smira]

Posted #807 to address this issue

[anlutro]

@smira as #807 was reverted in #857, can this be re-opened?

personally I think the simplest solution is just to add configuration or CLI options for socket ownership and file mode, e.g.
aptly api serve --listen="unix:///var/run/aptly.sock" --socket-chown="aptly:www-data" --socket-chmod="0770"