Обсуждение: BUG #15596: Folders created with wrong permissions when installing anextension with a non-default umask

Поиск
Список
Период
Сортировка

BUG #15596: Folders created with wrong permissions when installing anextension with a non-default umask

От
PG Bug reporting form
Дата:
The following bug has been logged on the website:

Bug reference:      15596
Logged by:          Antoine Amarilli
Email address:      a3nm.postgresql@a3nm.net
PostgreSQL version: 11.1
Operating system:   Debian testing
Description:

Hi,

I was trying to install a PostgreSQL extension (namely,
https://github.com/PierreSenellart/provsql). This extension uses the macros
in the file /usr/lib/postgresql/11/lib/pgxs/src/makefiles/pgxs.mk to install
itself, so running "make install" does the following:

/bin/mkdir -p '/usr/lib/postgresql/11/lib'
/bin/mkdir -p '/usr/share/postgresql/11/extension'
/bin/mkdir -p '/usr/share/postgresql/11/extension'
/bin/mkdir -p '/usr/share/doc/postgresql-doc-11/extension'
/usr/bin/install -c -m 755  provsql.so
'/usr/lib/postgresql/11/lib/provsql.so'
/usr/bin/install -c -m 644 .//provsql.control
'/usr/share/postgresql/11/extension/'
/usr/bin/install -c -m 644 .//sql/provsql--1.0.0-dev.sql
'/usr/share/postgresql/11/extension/'
/usr/bin/install -c -m 644 .//doc/provsql.md
'/usr/share/doc/postgresql-doc-11/extension/'
/bin/mkdir -p '/usr/lib/postgresql/11/lib/bitcode/provsql'
/bin/mkdir -p '/usr/lib/postgresql/11/lib/bitcode'/provsql/src/
...

However, the umask of my user is 077, so these "mkdir -p" invocations are
creating folders that can only be read by root, which is not the intended
behavior.

Would it be possible to fix this by redefining MKDIR_P="mkdir -m 0755 -p" in
pgxs.mk so that the mkdir invocations create the folders with the right
permissions, in line with the "install" invocations? Thanks!


=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> However, the umask of my user is 077, so these "mkdir -p" invocations are
> creating folders that can only be read by root, which is not the intended
> behavior.

So ... don't do that.

> Would it be possible to fix this by redefining MKDIR_P="mkdir -m 0755 -p" in
> pgxs.mk so that the mkdir invocations create the folders with the right
> permissions, in line with the "install" invocations? Thanks!

I think that would be a pretty bad idea, because it would break things
for packagers who have their own ideas about what the directory
permissions ought to be.

You can, of course, enforce your own ideas on the make run with something
like (untested)

    make MKDIR_P="mkdir -m 0755 -p" install

            regards, tom lane


Hi Tom,

On Wed, Jan 16, 2019 at 09:33:41PM -0500, Tom Lane wrote:
> =?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> > However, the umask of my user is 077, so these "mkdir -p" invocations are
> > creating folders that can only be read by root, which is not the intended
> > behavior.
>
> So ... don't do that.

Sure, when you've noticed the problem it's easy to work around it. But
when you haven't noticed it, doing "make install" appears to work fine
and then later things break in a confusing way because the files have
been installed and only root can read them. This makes the install
process quite counter-intuitive.

> > Would it be possible to fix this by redefining MKDIR_P="mkdir -m 0755 -p" in
> > pgxs.mk so that the mkdir invocations create the folders with the right
> > permissions, in line with the "install" invocations? Thanks!
>
> I think that would be a pretty bad idea, because it would break things
> for packagers who have their own ideas about what the directory
> permissions ought to be.

I see, but on the other hand all files are installed with
"/usr/bin/install -c -m 755" or "/usr/bin/install -c -m 644". If you're
deciding to make the files world-readable when installing them, why not
decide the same thing for the new directories that you create?

> You can, of course, enforce your own ideas on the make run with something
> like (untested)
>
>     make MKDIR_P="mkdir -m 0755 -p" install

Sure, thanks! I'll suggest this to the extension maintainer in case it
can't be fixed in Postgres.

Best,

--
Antoine Amarilli


Вложения