How can multiple users share their (uwsgi) sockets with nginx, but not with each other?Does systemd allow for...
Why escape if the_content isnt?
Term for the "extreme-extension" version of a straw man fallacy?
Applicability of Single Responsibility Principle
Trouble understanding the speech of overseas colleagues
How does buying out courses with grant money work?
Is `x >> pure y` equivalent to `liftM (const y) x`
Is there a good way to store credentials outside of a password manager?
How do I rename a Linux host without needing to reboot for the rename to take effect?
Would a high gravity rocky planet be guaranteed to have an atmosphere?
What is the intuitive meaning of having a linear relationship between the logs of two variables?
How can a function with a hole (removable discontinuity) equal a function with no hole?
How does it work when somebody invests in my business?
Sort a list by elements of another list
What is the difference between "behavior" and "behaviour"?
Can the discrete variable be a negative number?
How did Arya survive the stabbing?
Customer Requests (Sometimes) Drive Me Bonkers!
How easy is it to start Magic from scratch?
Is expanding the research of a group into machine learning as a PhD student risky?
How to check is there any negative term in a large list?
Failed to fetch jessie backports repository
Tiptoe or tiphoof? Adjusting words to better fit fantasy races
Roman Numeral Treatment of Suspensions
How can I get through very long and very dry, but also very useful technical documents when learning a new tool?
How can multiple users share their (uwsgi) sockets with nginx, but not with each other?
Does systemd allow for functionality like authbind? Where you can allow a non-root user to bind to a priv port?ACL users to change write permissionsHow can I see which flags Nginx was compiled with?Nginx, uWSGI, Python, users, groups and permissions. Questions about securityDoes uwsgi workers share a common memory ? [ With Nginx ]Samba Ignoring POSIX ACLsHow can I grant different rights to a group of users based on the ownership of a fileuwsgi configuration with Nginx, with python scripts as cgi - 502 Bad GatewayShare Permissions: Why can a group access a share, but not members of that group (Windows Server Environment)?How can I configure nginx with multiple uwsgi vassals (with websockets) in emperor mode?PHP-FPM socket reuse causes errors
On a shared domain, currently, each linux user sets up his website through his www-data-writable directory + uwsgi socket - one nginx instance serves them all.
However, I do not like the idea of one of those users potentially compromising the others (e.g., writing directly to uwsgi socket).
I want to share the sockets to the web server, but not among the users. How do i do that?
Solution 1: (bad, because complicated & error-prone) Add the webserver to user-specific groups.
nginx file-permissions groups uwsgi
asked Aug 9 '15 at 18:49
anxanx
1,8261821
add a comment |
On a shared domain, currently, each linux user sets up his website through his www-data-writable directory + uwsgi socket - one nginx instance serves them all.
However, I do not like the idea of one of those users potentially compromising the others (e.g., writing directly to uwsgi socket).
I want to share the sockets to the web server, but not among the users. How do i do that?
Solution 1: (bad, because complicated & error-prone) Add the webserver to user-specific groups.
nginx file-permissions groups uwsgi
asked Aug 9 '15 at 18:49
anxanx
1,8261821
If it is writable by the user, andwww-data, and nobody else, what is the problem?
– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
One solution may be to let the services use sockets created+chowned and passed to them by init as file descriptors (untested).
– anx
Mar 6 at 16:38
add a comment |
On a shared domain, currently, each linux user sets up his website through his www-data-writable directory + uwsgi socket - one nginx instance serves them all.
However, I do not like the idea of one of those users potentially compromising the others (e.g., writing directly to uwsgi socket).
I want to share the sockets to the web server, but not among the users. How do i do that?
Solution 1: (bad, because complicated & error-prone) Add the webserver to user-specific groups.
nginx file-permissions groups uwsgi
asked Aug 9 '15 at 18:49
anxanx
1,8261821
On a shared domain, currently, each linux user sets up his website through his www-data-writable directory + uwsgi socket - one nginx instance serves them all.
However, I do not like the idea of one of those users potentially compromising the others (e.g., writing directly to uwsgi socket).
I want to share the sockets to the web server, but not among the users. How do i do that?
Solution 1: (bad, because complicated & error-prone) Add the webserver to user-specific groups.
nginx file-permissions groups uwsgi
nginx file-permissions groups uwsgi
asked Aug 9 '15 at 18:49
anxanx
1,8261821
asked Aug 9 '15 at 18:49
anxanx
1,8261821
asked Aug 9 '15 at 18:49
anxanx
1,8261821
asked Aug 9 '15 at 18:49
anxanx
1,8261821
asked Aug 9 '15 at 18:49
anxanx
1,8261821
1,8261821
If it is writable by the user, andwww-data, and nobody else, what is the problem?
– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
One solution may be to let the services use sockets created+chowned and passed to them by init as file descriptors (untested).
– anx
Mar 6 at 16:38
add a comment |
If it is writable by the user, andwww-data, and nobody else, what is the problem?
– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
One solution may be to let the services use sockets created+chowned and passed to them by init as file descriptors (untested).
– anx
Mar 6 at 16:38
If it is writable by the user, and
www-data, and nobody else, what is the problem?– Michael Hampton♦
Aug 9 '15 at 18:57
If it is writable by the user, and
www-data, and nobody else, what is the problem?– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
One solution may be to let the services use sockets created+chowned and passed to them by init as file descriptors (untested).
– anx
Mar 6 at 16:38
One solution may be to let the services use sockets created+chowned and passed to them by init as file descriptors (untested).
– anx
Mar 6 at 16:38
add a comment |
1 Answer
1
active
oldest
votes
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 1 min ago
anxanx
1,8261821
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f712947%2fhow-can-multiple-users-share-their-uwsgi-sockets-with-nginx-but-not-with-each%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 1 min ago
anxanx
1,8261821
add a comment |
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 1 min ago
anxanx
1,8261821
add a comment |
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 1 min ago
anxanx
1,8261821
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 1 min ago
anxanx
1,8261821
answered 1 min ago
anxanx
1,8261821
answered 1 min ago
anxanx
1,8261821
answered 1 min ago
anxanx
1,8261821
1,8261821
add a comment |
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f712947%2fhow-can-multiple-users-share-their-uwsgi-sockets-with-nginx-but-not-with-each%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If it is writable by the user, and
www-data, and nobody else, what is the problem?– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
One solution may be to let the services use sockets created+chowned and passed to them by init as file descriptors (untested).
– anx
Mar 6 at 16:38