On 08/21/2018 02:20 PM, Warren Young wrote: > On Aug 21, 2018, at 1:27 PM, Nataraj <incoming-cen...@rjl.com> wrote: >> I have a web application which uses sudo to invoke python scripts as the >> user under which the application runs (NO root access). > Why is the web app not running with that user’s permissions in the first > place? > > If your answer is that it needs root access to bind to port 80, there are two > common solutions: > > 1. Start the service as root, set up the port 80 listener, then drop > privileges internally with getpwent(“myuser”) and setuid(my_uid). > > 2. Use an HTTP[S] proxy server, such as Apache with mod_proxy configured. > Bind the actual web app to localhost and a high-numbered random port, then > forward external port 80 hits to the internal service. This method has the > additional advantage that you can use the path part of the URL to relieves > the web app of having to serve hits for the static resources — *.js, *.png, > *.css… — which can speed the application up. > _______________________________________________ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos
The php code runs as user apache under the webserver. If the php ran as the app users it would have full access to all of the data in the app. Using sudo the app can only invoke one specific python script (which is the command name in the sudoers file) to do what it needs to do, without having access to the rest of the apps data and other python scripts used by other functions in the app). Could be that I'm not seeing something, but this approach seems sensible to me, though I could be convinced otherwise if I could see where running the php as the app users, would make more sense. It could be that giving sudo sys_ptrace access could increase the risk to the security of the system, but giving the php code app user access, increases the risk of data compromise in the app. Thank You, Nataraj _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
