Re: Additional role attributes && superuser review

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Additional role attributes && superuser review
Дата
Msg-id 20160118021023.GH3685@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Additional role attributes && superuser review  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Additional role attributes && superuser review  (Bruce Momjian <bruce@momjian.us>)
Re: Additional role attributes && superuser review  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
Bruce,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Sun, Jan 17, 2016 at 01:57:22PM -0500, Stephen Frost wrote:
> > Right, we also check in the backend on startup for certain permissions.
> > I don't recall offhand if that's forced to 700 or if we allow 750.
> >
> > > > I don't recall offhand if that means we'd have to make changes to allow
> > > > that, but, for my 2c, I don't see why we wouldn't allow it to be an
> > > > option.
> > >
> > > OK, that would be an initdb change then.
> >
> > It would need to be optional, so distributions and users could choose
> > which makes sense for their systems.
>
> While the group owner of the directory is a distributions question, the
> permissions are usually a backup-method-specific requirement.  I can see
> us creating an SQL function that opens up group permissions on the data
> directory for specific backup tools that need it, then granting
> permissions on that function to the backup role.   This is another
> example where different backup tools need different permissions.

I don't believe we can really consider group ownership and group
permissions independently.  They really go hand-in-hand.  On
RedHat-based system, where the group is set as 'staff', you probably
don't want group permissions to be allowed.  On Debian-based systems,
where there is a dedicated 'postgres' group, group permissions are fine
to allow.

Group ownership and permissions aren't a backup-method-specific
requirement either, in my view.  I'm happy to chat with Marco (who has
said he would be weighing in on this thread when he is able to)
regarding barman, and whomever would be appropriate for BART (perhaps
you could let me know..?), but if it's possible to do a backup without
being a superuser and with only read access to the data directory, I
would expect every backup soltuion to view that as a feature which they
want to support, as there are environments which will find it desirable,
at a minimum, and even some which will require it.

Lastly, I'm pretty sure this would have to be a postgresql.conf option
as we check the permissions on the data directory on startup.  I don't
see how having an SQL function would work there as I certainly wouldn't
want to have the permissions changing on a running system.  That strikes
me as being risky without any real benefit.  Either it's safe and
acceptable to allow those rights to the group, or it isn't.  A temproary
grant really isn't helping with anything that I can see, surely there
are numerous ways to exploit such a time-based grant.

Thanks!

Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: Combining Aggregates
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Additional role attributes && superuser review