Re: [PATCH] Add <> support to sepgsql_restorecon

> On 20 Mar 2023, at 21:17, Ted Toth wrote: > > Not this month unfortunately other work has taken precedence. I'll need to > look at what it's going to take to create a test. Hopefully I can piggyback > on an existing test. This patch has been marked Waiting on Author since January, I'm markin

Re: [PATCH] Add <> support to sepgsql_restorecon

Not this month unfortunately other work has taken precedence. I'll need to look at what it's going to take to create a test. Hopefully I can piggyback on an existing test. Ted On Mon, Mar 20, 2023 at 3:05 PM Gregory Stark (as CFM) wrote: > > Ok, sounds reasonable. Maybe just add a comment to th

Re: [PATCH] Add <> support to sepgsql_restorecon

> Ok, sounds reasonable. Maybe just add a comment to that effect. > This needs regression test support for the feature and some minimal > documentation that shows how to make use of it. Hm. It sounds like this patch is uncontroversial but is missing documentation and tests? Has this been address

Re: [PATCH] Add <> support to sepgsql_restorecon

On Wed, 18 Jan 2023 at 23:57, Joe Conway wrote: > > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: not tested > Spec compliant: not tested > Documentation:not tested > > This needs re

Re: [PATCH] Add <> support to sepgsql_restorecon

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested This needs regression test support for the feature and some minimal document

Re: [PATCH] Add <> support to sepgsql_restorecon

The intent of this patch is not to stop all relabeling only to stop sepgsql_restorecon from doing a bulk relabel. I believe sepgsql_object_relabel is called by the 'SECURITY LABEL' statement which I'm using to set the label of db objects to a specific context which I would not want altered late

Re: [PATCH] Add <> support to sepgsql_restorecon

On 1/16/23 09:55, Ted Toth wrote: On Sun, Jan 15, 2023 at 1:11 PM Joe Conway > wrote: On 11/21/22 17:35, Joe Conway wrote: > On 11/21/22 15:57, Ted Toth wrote: >> In SELinux file context files you can specify <> for a file >> meaning you don't wan

Re: [PATCH] Add <> support to sepgsql_restorecon

On Sun, Jan 15, 2023 at 1:11 PM Joe Conway wrote: > On 11/21/22 17:35, Joe Conway wrote: > > On 11/21/22 15:57, Ted Toth wrote: > >> In SELinux file context files you can specify <> for a file > >> meaning you don't want restorecon to relabel it. <> is > >> especially useful in an SELinux MLS env

Re: [PATCH] Add <> support to sepgsql_restorecon

On 11/21/22 17:35, Joe Conway wrote: On 11/21/22 15:57, Ted Toth wrote: In SELinux file context files you can specify <> for a file meaning you don't want restorecon to relabel it. <> is especially useful in an SELinux MLS environment when objects are created at a specific security level and you

Re: [PATCH] Add <> support to sepgsql_restorecon

On 11/21/22 15:57, Ted Toth wrote: In SELinux file context files you can specify <> for a file meaning you don't want restorecon to relabel it. <> is especially useful in an SELinux MLS environment when objects are created at a specific security level and you don't want restorecon to relabel them

[PATCH] Add <> support to sepgsql_restorecon

In SELinux file context files you can specify <> for a file meaning you don't want restorecon to relabel it. <> is especially useful in an SELinux MLS environment when objects are created at a specific security level and you don't want restorecon to relabel them to the wrong security level. Ted