Re: security_context_t marked as deprecated in libselinux 3.1

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: security_context_t marked as deprecated in libselinux 3.1
Date: 2022-11-03 23:49:24
Message-ID: Y2RThIizCVQkV0tN@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 03, 2022 at 07:01:20PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
>> FWIW I just had a CI job fail the "warnings" test because of lacking
>> this patch in the back branches :-) What do you think about
>> back-patching this to at least 11?
>
> No objection to back-patching from me.

Fine by me.

>> I would say 10, but since that one
>> is going to end soon, it might not be worth much effort. OTOH maybe we
>> want to backpatch all the way back to 9.2 given the no-warnings policy
>> we recently acquired.
>
> I'm not sure that no-warnings policy extends to stuff as far off the
> beaten path as sepgsql. However, I won't stand in the way if you
> want to do that. One point though: if you want to touch v10, I'd
> suggest waiting till after next week's releases. Unlikely as it
> is that this'd break anything, I don't think we should risk it
> in the branch's last release.

In line of ad96696, seems like that it would make sense to do the same
here even if the bar is lower. sepgsql has not changed in years, so I
suspect few conflicts. Alvaro, if you want to take care of that,
that's fine by me. I could do it, but not before next week.

Agreed to wait after the next minor release.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ian Lawrence Barwick 2022-11-04 00:32:52 Re: In-placre persistance change of a relation
Previous Message Ian Lawrence Barwick 2022-11-03 23:46:02 Re: ExecRTCheckPerms() and many prunable partitions