-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
rhel-10.0
-
None
-
rhel-fs-vfs
-
None
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
None
Description of problem:
In RHEL 7 and RHEL 8, the manpage for request-key.conf(5) states:
<op> <type> <description> <callout-info> <prog> <arg1> <arg2> ...
The first four fields are used to match the parameters passed to
request-key by the kernel. op is the operation type; currently the
only supported operation is "create".
type, description and callout-info match the three parameters
passed to keyctl request2 or the request_key() system call. Each of
these may contain one or more asterisk '*' characters as wildcards
anywhere within the string.
However the code in keyutils.c states that only one asterisk is allowed in the entire pattern:
/*****************************************************************************/
/*
* attempt to match a datum to a pattern
* - one asterisk is allowed anywhere in the pattern to indicate a wildcard
* - returns true if matched, false if not
*/
static int match(const char *pattern, int plen, const char *datum, int dlen)
And the manpage was (correctly) updated in RHEL 9 to state that only one asterisk was allowed.
This is a request for enhancement to support multiple wildcards.
Multiple wildcards are necessary in some cases where multiple dynamic fields exist, for example with cifs.spnego:
ver=0x2;host=SERVER_HOSTNAME;ip4=SERVER_IP;sec=krb5;uid=0x0;creduid=0x0;user=USERNAME;pid=PID
Version-Release number of selected component (if applicable):
keyutils-1.5.10-9.el8.x86_64
How reproducible:
easy
Steps to Reproduce:
Attempt to match with multiple asterisks in the relevant request-key file:
/etc/request-key.d/cifs.spnego.conf
create cifs.spnego ver=*;host=*;ip4=*;sec=krb5;uid=0x0;creduid=0x0;user=MYUSER1@*,pid=* /usr/sbin/cifs.upcall -t /path/to/MYUSER1.keytab %k create cifs.spnego ver=*;host=*;ip4=*;sec=krb5;uid=0x0;creduid=0x0;user=MYUSER2@*,pid=* /usr/sbin/cifs.upcall -t /path/to/MYUSER2.keytab %k
attempt to mount a cifs share using krb5 (it is not necessary to actually have cifs+kerberos set up correctly):
# mount //server/share /mnt/tmp -o sec=krb5,user=MYUSER1 # mount //server/share /mnt/tmp -o sec=krb5,user=MYUSER2
Actual results:
strings with multiple wildcards will not match
Expected results:
multiple wildcards are accepted, and work as described in the manpage
Additional info:
The RHEL 8 manpage says:
Each of these may contain one or more asterisk '*' characters as wildcards anywhere within the string."
but this was changed, and it now reads:
Each of these may contain one asterisk '*' character as a wildcard anywhere within the string.
in RHEL 9+
the commit changing the manpage was:
commit e8234d788e3be1801e5eebe4096b1d9e839023a6
Author: David Howells <dhowells@redhat.com>
Date: Tue Sep 4 11:07:59 2018 +0100
request-key: Find best match rather than first match
When an upcall happens currently, either a file by the name
"/etc/request-key.d/<type>.conf" is scanned or the default file
"/etc/request-key.conf" is scanned and then the first match (including
wildcards) is selected.
Change this to read all the files in the conf directory and then read the
default file. The best rule is then chosen and executed.
"Best" is defined as the rule with the least number of characters that are
skipped by matching a wildcard (e.g. string "foo:bar" matches pattern
"foo:*" with the number of characters being skipped being 3).
Further, the operation, type, description and callout_info columns are
matched individually and in order, so that a skip of 1 in the operation
column, say, is less preferable than an exact match there and a skip of 2
in the type column.
For example, take:
create dns_resolver afsdb:* * /sbin/key.afsdb %k
create dns_resolver afsdb:* hello* /sbin/key.xxxx %k
if both lines match, the second one will be picked, but, on the other hand,
with:
create dns_resolver afsdb:* * /sbin/key.afsdb %k
creat* dns_resolver afsdb:* hello* /sbin/key.xxxx %k
the first will be picked.
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Dave Jiang <dave.jiang@intel.com>
- is related to
-
-
- Closed
-
