Changing ownership of proxy_temp and other temp directories

[Shreenidhi Shedi]

Thanks for the response Sergey A. Osokin.

The problem is these temp locations are configurable parameters. So, from a spec file perspective it's hard to fetch these parameters and change the permissions.

As ngnix is already doing the task of changing permission of top directory, is there any problem the same recursively?

Sorry, I'm using outlook so I don't know how to reply below your message, so it's a bit difficult. Apologies for that.

--
Shedi
________________________________
From: Sergey A. Osokin <osa at freebsd.org.ru>
Sent: 17 March 2023 02:46
To: nginx at nginx.org <nginx at nginx.org>
Cc: Shreenidhi Shedi <sshedi at vmware.com>
Subject: Re: Changing ownership of proxy_temp and other temp directories

!! External Email

Hi,

On Thu, Mar 16, 2023 at 06:19:42PM +0000, Shreenidhi Shedi via nginx wrote:
>
> I have hosted a nginx server instance and the temp directories are created under /etc/nginx/
>
> $ ls -ld /etc/nginx/*_temp
> drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/client_body_temp
[...]
>
> And I updated to a newer version of nginx which runs in "nginx" user
> context and after that these directory ownership is getting changed
> to nginx:root but the issue is, it happens only on these top
> directories and not directories within these temp directories.
>
> I did strace on the same to confirm my theory.

[strace is skipped]

It seems like previously nginx' worker process was running under
`nobody' user, so the directory structure has appropriate
permissions.  The configuration setting was changed to `nginx'
user then, and when nginx main process started, it checked and
updated directories permissions according to the new settings.

> Now the issue is, why chown happens only on top directory and
> not recursively on all files and directories inside them?

Please take a look in the source code,
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.nginx.org%2Fnginx%2Ffile%2Ftip%2Fsrc%2Fcore%2Fngx_file.c%23l598&data=05%7C01%7Csshedi%40vmware.com%7Ccc1606f4494b48ed496308db2663c194%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638145982140985501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BnlexAGf4iaOhxIl0GnCZOGUfufWlJyuefJOFP%2Bvb6I%3D&reserved=0

> Is this a bug or is it fixed in latest version of nginx?

I don't think there's a bug in that part of the code.
As a workaround for the transition content to a new user, it's
easy to run an one line script to update permissions of those
directories.

> I'm currently using nginx-1.22.0. Any help would be appreciated.

I'd recommend to upgrade to the recent version in stable
branch, 1.22.1.

Thank you.

--
Sergey A. Osokin

!! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230317/71df953f/attachment.htm>