This patch adds a flag, FAN_INFO and an extensible buffer to provide additional information about response decisions. The buffer contains one or more headers defining the information type and the length of the following information. The patch defines one additional information type, FAN_RESPONSE_INFO_AUDIT_RULE, an audit rule number. This will allow for the creation of other information types in the future if other users of the API identify different needs. Suggested-by: Steve Grubb <sgrubb(a)redhat.com&gt; Link: https://lore.kernel.org/r/2745105.e9J7NaK4W3@x2 Suggested-by: Jan Kara <jack(a)suse.cz&gt; Link: https://lore.kernel.org/r/20201001101219.GE17860@quack2.suse.cz Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com&gt; --- fs/notify/fanotify/fanotify.c | 10 ++- fs/notify/fanotify/fanotify.h | 2 + fs/notify/fanotify/fanotify_user.c | 104 +++++++++++++++++++++++------ include/linux/fanotify.h | 5 ++ include/uapi/linux/fanotify.h | 27 +++++++- 5 files changed, 123 insertions(+), 25 deletions(-) diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index 4f897e109547..0f36062521f4 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -262,13 +262,16 @@ static int fanotify_get_response(struct fsnotify_group *group, } /* userspace responded, convert to something usable */ - switch (event->response & ~FAN_AUDIT) { + switch (event->response & FANOTIFY_RESPONSE_ACCESS) { case FAN_ALLOW: ret = 0; break; case FAN_DENY: - default: ret = -EPERM; + break; + default: + ret = -EINVAL; + break; } /* Check if the response should be audited */ @@ -560,6 +563,8 @@ static struct fanotify_event *fanotify_alloc_perm_event(const struct path *path, pevent->fae.type = FANOTIFY_EVENT_TYPE_PATH_PERM; pevent->response = 0; + pevent->info_len = 0; + pevent->info_buf = NULL; pevent->state = FAN_EVENT_INIT; pevent->path = *path; path_get(path); @@ -996,6 +1001,7 @@ static void fanotify_free_path_event(struct fanotify_event *event) static void fanotify_free_perm_event(struct fanotify_event *event) { path_put(fanotify_event_path(event)); + kfree(FANOTIFY_PERM(event)->info_buf); kmem_cache_free(fanotify_perm_event_cachep, FANOTIFY_PERM(event)); } diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h index abfa3712c185..14c30e173632 100644 --- a/fs/notify/fanotify/fanotify.h +++ b/fs/notify/fanotify/fanotify.h @@ -428,6 +428,8 @@ struct fanotify_perm_event { u32 response; /* userspace answer to the event */ unsigned short state; /* state of the event */ int fd; /* fd we passed to userspace for this event */ + size_t info_len; + char *info_buf; }; static inline struct fanotify_perm_event * diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c index ff67ca0d25cc..a4ae953f0e62 100644 --- a/fs/notify/fanotify/fanotify_user.c +++ b/fs/notify/fanotify/fanotify_user.c @@ -289,13 +289,18 @@ static int create_fd(struct fsnotify_group *group, struct path *path, */ static void finish_permission_event(struct fsnotify_group *group, struct fanotify_perm_event *event, - u32 response) + struct fanotify_response *response, + size_t info_len, char *info_buf) __releases(&group->notification_lock) { bool destroy = false; assert_spin_locked(&group->notification_lock); - event->response = response; + event->response = response->response & ~FAN_INFO; + if (response->response & FAN_INFO) { + event->info_len = info_len; + event->info_buf = info_buf; + } if (event->state == FAN_EVENT_CANCELED) destroy = true; else @@ -306,33 +311,71 @@ static void finish_permission_event(struct fsnotify_group *group, } static int process_access_response(struct fsnotify_group *group, - struct fanotify_response *response_struct) + struct fanotify_response *response_struct, + const char __user *buf, + size_t count) { struct fanotify_perm_event *event; int fd = response_struct->fd; u32 response = response_struct->response; + struct fanotify_response_info_header info_hdr; + char *info_buf = NULL; - pr_debug("%s: group=%p fd=%d response=%u\n", __func__, group, - fd, response); + pr_debug("%s: group=%p fd=%d response=%u buf=%p size=%lu\n", __func__, + group, fd, response, info_buf, count); /* * make sure the response is valid, if invalid we do nothing and either * userspace can send a valid response or we will clean it up after the * timeout */ - switch (response & ~FAN_AUDIT) { + if (response & ~FANOTIFY_RESPONSE_VALID_MASK) + return -EINVAL; + switch (response & FANOTIFY_RESPONSE_ACCESS) { case FAN_ALLOW: case FAN_DENY: break; default: return -EINVAL; } - - if (fd < 0) - return -EINVAL; - if ((response & FAN_AUDIT) && !FAN_GROUP_FLAG(group, FAN_ENABLE_AUDIT)) return -EINVAL; + if (fd < 0) + return -EINVAL; + if (response & FAN_INFO) { + size_t c = count; + const char __user *ib = buf; + if (c <= 0) + return -EINVAL; + while (c >= sizeof(info_hdr)) { + if (copy_from_user(&info_hdr, ib, sizeof(info_hdr))) + return -EFAULT; + if (info_hdr.pad != 0) + return -EINVAL; + if (c < info_hdr.len) + return -EINVAL; + switch (info_hdr.type) { + case FAN_RESPONSE_INFO_AUDIT_RULE: + break; + case FAN_RESPONSE_INFO_NONE: + default: + return -EINVAL; + } + c -= info_hdr.len; + ib += info_hdr.len; + } + if (c != 0) + return -EINVAL; + /* Simplistic check for now */ + if (count != sizeof(struct fanotify_response_info_audit_rule)) + return -EINVAL; + info_buf = kmalloc(sizeof(struct fanotify_response_info_audit_rule), + GFP_KERNEL); + if (!info_buf) + return -ENOMEM; + if (copy_from_user(info_buf, buf, count)) + return -EFAULT; + } spin_lock(&group->notification_lock); list_for_each_entry(event, &group->fanotify_data.access_list, fae.fse.list) { @@ -340,7 +383,9 @@ static int process_access_response(struct fsnotify_group *group, continue; list_del_init(&event->fae.fse.list); - finish_permission_event(group, event, response); + /* finish_permission_event() eats info_buf */ + finish_permission_event(group, event, response_struct, + count, info_buf); wake_up(&group->fanotify_data.access_waitq); return 0; } @@ -802,9 +847,14 @@ static ssize_t fanotify_read(struct file *file, char __user *buf, fsnotify_destroy_event(group, &event->fse); } else { if (ret <= 0) { + struct fanotify_response response = { + .fd = FAN_NOFD, + .response = FAN_DENY }; + spin_lock(&group->notification_lock); finish_permission_event(group, - FANOTIFY_PERM(event), FAN_DENY); + FANOTIFY_PERM(event), &response, + 0, NULL); wake_up(&group->fanotify_data.access_waitq); } else { spin_lock(&group->notification_lock); @@ -827,26 +877,33 @@ static ssize_t fanotify_read(struct file *file, char __user *buf, static ssize_t fanotify_write(struct file *file, const char __user *buf, size_t count, loff_t *pos) { - struct fanotify_response response = { .fd = -1, .response = -1 }; + struct fanotify_response response; struct fsnotify_group *group; int ret; + const char __user *info_buf = buf + sizeof(struct fanotify_response); + size_t c; if (!IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS)) return -EINVAL; group = file->private_data; - if (count < sizeof(response)) - return -EINVAL; - - count = sizeof(response); - pr_debug("%s: group=%p count=%zu\n", __func__, group, count); - if (copy_from_user(&response, buf, count)) + if (count < sizeof(response)) + return -EINVAL; + if (copy_from_user(&response, buf, sizeof(response))) return -EFAULT; - ret = process_access_response(group, &response); + c = count - sizeof(response); + if (response.response & FAN_INFO) { + if (c < sizeof(struct fanotify_response_info_header)) + return -EINVAL; + } else { + if (c != 0) + return -EINVAL; + } + ret = process_access_response(group, &response, info_buf, c); if (ret < 0) count = ret; @@ -857,6 +914,9 @@ static int fanotify_release(struct inode *ignored, struct file *file) { struct fsnotify_group *group = file->private_data; struct fsnotify_event *fsn_event; + struct fanotify_response response = { + .fd = FAN_NOFD, + .response = FAN_ALLOW }; /* * Stop new events from arriving in the notification queue. since @@ -876,7 +936,7 @@ static int fanotify_release(struct inode *ignored, struct file *file) event = list_first_entry(&group->fanotify_data.access_list, struct fanotify_perm_event, fae.fse.list); list_del_init(&event->fae.fse.list); - finish_permission_event(group, event, FAN_ALLOW); + finish_permission_event(group, event, &response, 0, NULL); spin_lock(&group->notification_lock); } @@ -893,7 +953,7 @@ static int fanotify_release(struct inode *ignored, struct file *file) fsnotify_destroy_event(group, fsn_event); } else { finish_permission_event(group, FANOTIFY_PERM(event), - FAN_ALLOW); + &response, 0, NULL); } spin_lock(&group->notification_lock); } diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h index edc28555814c..ce9f97eb69f2 100644 --- a/include/linux/fanotify.h +++ b/include/linux/fanotify.h @@ -114,6 +114,11 @@ #define ALL_FANOTIFY_EVENT_BITS (FANOTIFY_OUTGOING_EVENTS | \ FANOTIFY_EVENT_FLAGS) +/* This mask is to check for invalid bits of a user space permission response */ +#define FANOTIFY_RESPONSE_ACCESS (FAN_ALLOW | FAN_DENY) +#define FANOTIFY_RESPONSE_FLAGS (FAN_AUDIT | FAN_INFO) +#define FANOTIFY_RESPONSE_VALID_MASK (FANOTIFY_RESPONSE_ACCESS | FANOTIFY_RESPONSE_FLAGS) + /* Do not use these old uapi constants internally */ #undef FAN_ALL_CLASS_BITS #undef FAN_ALL_INIT_FLAGS diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h index f1f89132d60e..4d08823a5698 100644 --- a/include/uapi/linux/fanotify.h +++ b/include/uapi/linux/fanotify.h @@ -180,15 +180,40 @@ struct fanotify_event_info_error { __u32 error_count; }; +/* + * User space may need to record additional information about its decision. + * The extra information type records what kind of information is included. + * The default is none. We also define an extra information buffer whose + * size is determined by the extra information type. + * + * If the context type is Rule, then the context following is the rule number + * that triggered the user space decision. + */ + +#define FAN_RESPONSE_INFO_NONE 0 +#define FAN_RESPONSE_INFO_AUDIT_RULE 1 + struct fanotify_response { __s32 fd; __u32 response; }; +struct fanotify_response_info_header { + __u8 type; + __u8 pad; + __u16 len; +}; + +struct fanotify_response_info_audit_rule { + struct fanotify_response_info_header hdr; + __u32 audit_rule; +}; + /* Legit userspace responses to a _PERM event */ #define FAN_ALLOW 0x01 #define FAN_DENY 0x02 -#define FAN_AUDIT 0x10 /* Bit mask to create audit record for result */ +#define FAN_AUDIT 0x10 /* Bitmask to create audit record for result */ +#define FAN_INFO 0x20 /* Bitmask to indicate additional information */ /* No fd set in event */ #define FAN_NOFD -1 -- 2.27.0

On Fri 12-08-22 10:23:13, Matthew Bobrowski wrote: ... So the check for (c != 0) in case FAN_INFO is not set is definitely asking for userspace regression because before we have been just silently ignoring additional bytes beyond standard reply. So please keep the old behavior of ignoring extra bytes if FAN_INFO flag is not set. Thanks! Honza -- Jan Kara <jack(a)suse.com&gt; SUSE Labs, CR

This patch passes the full value so that the audit function can use all of it. The audit function was updated to log the additional information in the AUDIT_FANOTIFY record. The following is an example of the new record format: type=FANOTIFY msg=audit(1600385147.372:590): resp=2 fan_type=1 fan_info=17 Suggested-by: Steve Grubb <sgrubb(a)redhat.com&gt; Link: https://lore.kernel.org/r/3075502.aeNJFYEL58@x2 Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com&gt; --- fs/notify/fanotify/fanotify.c | 3 ++- include/linux/audit.h | 9 +++++---- kernel/auditsc.c | 31 ++++++++++++++++++++++++++++--- 3 files changed, 35 insertions(+), 8 deletions(-) diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c index 0f36062521f4..36c3ed1af085 100644 --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -276,7 +276,8 @@ static int fanotify_get_response(struct fsnotify_group *group, /* Check if the response should be audited */ if (event->response & FAN_AUDIT) - audit_fanotify(event->response & ~FAN_AUDIT); + audit_fanotify(event->response & ~FAN_AUDIT, + event->info_len, event->info_buf); pr_debug("%s: group=%p event=%p about to return ret=%d\n", __func__, group, event, ret); diff --git a/include/linux/audit.h b/include/linux/audit.h index 3ea198a2cd59..c69efdba12ca 100644 --- a/include/linux/audit.h +++ b/include/linux/audit.h @@ -14,6 +14,7 @@ #include <linux/audit_arch.h> #include <uapi/linux/audit.h> #include <uapi/linux/netfilter/nf_tables.h> +#include <uapi/linux/fanotify.h> #define AUDIT_INO_UNSET ((unsigned long)-1) #define AUDIT_DEV_UNSET ((dev_t)-1) @@ -417,7 +418,7 @@ extern void __audit_log_capset(const struct cred *new, const struct cred *old); extern void __audit_mmap_fd(int fd, int flags); extern void __audit_openat2_how(struct open_how *how); extern void __audit_log_kern_module(char *name); -extern void __audit_fanotify(u32 response); +extern void __audit_fanotify(u32 response, size_t len, char *buf); extern void __audit_tk_injoffset(struct timespec64 offset); extern void __audit_ntp_log(const struct audit_ntp_data *ad); extern void __audit_log_nfcfg(const char *name, u8 af, unsigned int nentries, @@ -524,10 +525,10 @@ static inline void audit_log_kern_module(char *name) __audit_log_kern_module(name); } -static inline void audit_fanotify(u32 response) +static inline void audit_fanotify(u32 response, size_t len, char *buf) { if (!audit_dummy_context()) - __audit_fanotify(response); + __audit_fanotify(response, len, buf); } static inline void audit_tk_injoffset(struct timespec64 offset) @@ -684,7 +685,7 @@ static inline void audit_log_kern_module(char *name) { } -static inline void audit_fanotify(u32 response) +static inline void audit_fanotify(u32 response, size_t len, char *buf) { } static inline void audit_tk_injoffset(struct timespec64 offset) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index 433418d73584..f000fec52360 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -64,6 +64,7 @@ #include <uapi/linux/limits.h> #include <uapi/linux/netfilter/nf_tables.h> #include <uapi/linux/openat2.h> // struct open_how +#include <uapi/linux/fanotify.h> #include "audit.h" @@ -2899,10 +2900,34 @@ void __audit_log_kern_module(char *name) context->type = AUDIT_KERN_MODULE; } -void __audit_fanotify(u32 response) +void __audit_fanotify(u32 response, size_t len, char *buf) { - audit_log(audit_context(), GFP_KERNEL, - AUDIT_FANOTIFY, "resp=%u", response); + struct fanotify_response_info_audit_rule *friar; + size_t c = len; + char *ib = buf; + + if (!(len && buf)) { + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, + "resp=%u fan_type=0 fan_info=?", response); + return; + } + while (c >= sizeof(struct fanotify_response_info_header)) { + friar = (struct fanotify_response_info_audit_rule *)buf; + switch (friar->hdr.type) { + case FAN_RESPONSE_INFO_AUDIT_RULE: + if (friar->hdr.len < sizeof(*friar)) { + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, + "resp=%u fan_type=%u fan_info=(incomplete)", + response, friar->hdr.type); + return; + } + audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, + "resp=%u fan_type=%u fan_info=%u", + response, friar->hdr.type, friar->audit_rule); + } + c -= friar->hdr.len; + ib += friar->hdr.len; + } } void __audit_tk_injoffset(struct timespec64 offset) -- 2.27.0

On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: You've hopefully already seen the kernel test robot build warning, so I won't bring that up again, but a few comments below ... Since the only use of this at the moment is the fanotify_response_info_rule, why not pass the fanotify_response_info_rule struct directly into this function? We can always change it if we need to in the future without affecting userspace, and it would simplify the code. -- paul-moore.com

On Wednesday, August 31, 2022 5:07:25 PM EDT Richard Guy Briggs wrote: I don't see a reason for sending more than one header. What is more probable is the need to send additional data in that header. I was thinking of maybe bit mapping it in the rule number. But I'd suggest padding the struct just in case it needs expanding some day. -Steev

On Wednesday, August 31, 2022 6:19:40 PM EDT Richard Guy Briggs wrote: I don't forsee that. It's much better to pad the struct so that the size doesn't change. It is a write syscall. I'd silently discard everything else and document that in the man pages. But the fanotify maintainers should really weigh in on this. I do not forsee a need for this. Could be a thousand. But I already know some missing information we'd like to return to user space in an audit event, so the bit mapping on the rule number might happen. I'd suggest padding one u32 for future use. -Steve

On Wed 31-08-22 21:47:09, Paul Moore wrote: We already do have the 'type' and 'len' fields in struct fanotify_response_info_header. So if audit needs to pass more information, we can define a new 'type' and either make it replace the current struct fanotify_response_info_audit_rule or make it expand the information in it. At least this is how we handle similar situation when fanotify wants to report some new bits of information to userspace. That being said if audit wants to have u32 pad in its struct fanotify_response_info_audit_rule for future "optional" expansion I'm not strictly opposed to that but I don't think it is a good idea. It is tricky to safely start using the new field. Audit subsystem can define that the kernel currently just ignores the field. And new kernel could start using the passed information in the additional field but that is somewhat risky because until that moment userspace can be passing random garbage in that unused field and thus break when running on new kernel that tries to make sense of it. Sure you can say it is broken userspace that does not properly initialize the padding field but history has shown us multiple times that events like these do happen and the breakage was unpleasant enough for users that the kernel just had to revert back to ignoring the field. Alternatively the kernel could bail with error if the new field is non-zero but that would block new userspace using that field from running on old kernel. But presumably the new userspace could be handling the error and writing another response with new field zeroed out. That would be a safe option although not very different from defining a new response type. Ultimately I guess I'll leave it upto audit subsystem what it wants to have in its struct fanotify_response_info_audit_rule because for fanotify subsystem, it is just an opaque blob it is passing. Honza -- Jan Kara <jack(a)suse.com&gt; SUSE Labs, CR

On 2022-09-01 14:31, Paul Moore wrote: This is what I expected would be the way to manage changing requirements. Agreed. Steve, please define the type and name of this additional field. I'm not particularly enthusiastic of "u32 pad;" - RGB -- Richard Guy Briggs <rgb(a)redhat.com&gt; Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635

Currently the only type of fanotify info that is defined is an audit rule number, but convert it to hex encoding to future-proof the field. Sample record: type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F Suggested-by: Paul Moore <paul(a)paul-moore.com&gt; Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com&gt; --- kernel/auditsc.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index f000fec52360..0f747015c577 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len, char *buf) if (!(len && buf)) { audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, - "resp=%u fan_type=0 fan_info=?", response); + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */ return; } while (c >= sizeof(struct fanotify_response_info_header)) { + struct audit_context *ctx = audit_context(); + struct audit_buffer *ab; + friar = (struct fanotify_response_info_audit_rule *)buf; switch (friar->hdr.type) { case FAN_RESPONSE_INFO_AUDIT_RULE: if (friar->hdr.len < sizeof(*friar)) { - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, - "resp=%u fan_type=%u fan_info=(incomplete)", - response, friar->hdr.type); + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY); + if (ab) { + audit_log_format(ab, "resp=%u fan_type=%u fan_info=", + response, friar->hdr.type); +#define INCOMPLETE "(incomplete)" + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE)); + audit_log_end(ab); + } return; } - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, - "resp=%u fan_type=%u fan_info=%u", - response, friar->hdr.type, friar->audit_rule); + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY); + if (ab) { + audit_log_format(ab, "resp=%u fan_type=%u fan_info=", + response, friar->hdr.type); + audit_log_n_hex(ab, (char *)&friar->audit_rule, + sizeof(friar->audit_rule)); + audit_log_end(ab); + + } } c -= friar->hdr.len; ib += friar->hdr.len; -- 2.27.0

On 2022-08-10 15:15, Steve Grubb wrote: That's quite an introduction! ;-) Well, if it is to be consistently hex encoded, that corresponds to "?" if it is to be interpreted as a string. Since the fan_type is 0, fan_info would be invalid, so a value of 0 would be entirely reasonable, hex encoded to fan_info=00. It could also be hex encoded to the string "(none)". If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE, that would be fan_info=30 if it were interpreted as a string, or arguably 3F for an integer of rule (decimal) 63. Ultimately, fan_type should determine how fan_info's hex encoded value should be interpreted. But ultimately, the point of this patch is to hex encode the fan_info field value. - RGB -- Richard Guy Briggs <rgb(a)redhat.com&gt; Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635

On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: This needs to be squashed with patch 3/4; it's a user visible change so we don't want someone backporting 3/4 without 4/4, especially when it is part of the same patchset. Please drop the trailing comment, it's not necessary and it makes the code messier. Is the distinction between "?" and "(incomplete)" really that important? I'm not going to go digging through all of the audit_log_format() callers to check, but I believe there is precedence for using "?" not only for when a value is missing, but when it is bogus as well. If we are really going to use "(incomplete)" here, let's do a better job than defining a macro mid-function and only using it in one other place - the line immediately below the definition. This is both ugly and a little silly (especially when one considers that the macro name is almost exactly the same as the string it replaces. If we must use "(incomplete)" here, just ditch the macro; any conceptual arguments about macros vs literals is largely rendered moot since there is only one user. -- paul-moore.com

On 2022-08-16 09:37, Steve Grubb wrote: Sure, these seem reasonable. - RGB -- Richard Guy Briggs <rgb(a)redhat.com&gt; Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635