chmod and chown for unix socket as listener

[echolimazulu]

Feature 1 - chmod:

An extension to the build and run configuration options that set the permission mode for a unix socket as a listener.

Configuration option:
NXT_UNIX_DOMAIN_MODE=MODE

Launch option:
--unix-sock-mod MODE

Available formats (for example: MODE 7):
NXT_UNIX_DOMAIN_MODE=7 or --unix-sock-mod 7
NXT_UNIX_DOMAIN_MODE=07 or --unix-sock-mod 07
NXT_UNIX_DOMAIN_MODE=007 or --unix-sock-mod 007

Default MODE value:
666 - (srw-rw-rw-)

Feature 2 - chown:

Set the user and group of the owner of the unix socket as a listener.

[mar0x]

Hello,
What is the use case when socket directory access rights is not enough?

[echolimazulu]

Hello mar0x,

Thank you for your attention!

I hope that I correctly understood the question you asked.

Long answer:
Then the unix socket will not initially be created and the error will occur at the time of trying to open the file descriptor, but this is not part of this PR and the code in it.

If we are talking about the availability of the sockets directory after changing the mode and owner for the socket from the common root to the base user, then with the default permissions of 666, this will not break the accessibility of the socket. Also, mode changes and owner determination affect the unix socket itself, not the directory in which it is located. If it is necessary for the user to specify a different value, the user has an obligation to provide accessibility control:

• adding a special user to run the program;
• adding a user to the necessary working groups (for example: for communication with other programs);
• providing access to the working directory with sockets;
• control over a sufficient minimum of permissions of the socket itself.

It is initially assumed that the main process (master) run as root, which forks processes, creates a unix socket and assigns the necessary permissions to it and sets the owner, by default has the necessary privileges for these operations. But even if the main process (master) is not started as root, this will not be a problem if the user initially takes care of the work of the program being launched and the working environment it needs. If the user has not done this, user will have a number of other problems (for example: with logging, control-socket, etc.) that do not affect the unix socket as a listener and the procedures applied to it (chmod & chown).

In most of the software that I have used before: nginx, php-fpm, uWSGI and many others, access control is the responsibility of the user, not the program. Otherwise, an error occurs when the program starts or when trying to open a socket. Often, the lack of this control on the part of the user leads to the impossibility of opening a file descriptor or subsequent writing by a running program to a unix socket, which leads to http error codes: 500, 502, 503.

For the sake of general compatibility, I left the not recommended mode: NXT_UNIX_DOMAIN_MODE=666, allowing everyone to read and write to the opened socket, as it was before when the bit set was used: (S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH).

If didn't answer your question, please let me know by providing a little more information about your question. Thank you again.

[mar0x]

Thank you for such a detailed answer.
I misread your patch, sorry (there are too many files changed).

So, you offer to set access rights for all unix sockets created during Unit running. I think it is not flexible and access right should be set for each socket individually. What do you think?

[mar0x]

Indeed, I would like to repeat my original question.

Currently, access rights can be granularly controlled using directory access rights. Administrator is responsible for creating directories where Unit will create unix domain sockets. Admin may setup desired access rights for directories (user, group, access mode).

What are the benefits of tuning per-socket rights?

[echolimazulu]

Good afternoon @mar0x,

Good question!

I didn't initially recognize the concept of using directory permissions with user and group directives in application. Therefore, I recognize that the current and already available scheme in Unit is more flexible and convenient in terms of real-world application. At the moment, I do not see much use for the concept I proposed, which would stand out noticeably better compared to the existing one. We can close the current PR, at least until it finds a suitable use.

[VBart]

Anyway, Unit command line options are only used to setup basic parameters essential for initialization and run. Anything else must be configured via control API, including listening sockets options (especially as the listening sockets themself are configured dynamically via this API).