Skip to content

Add request-key.d/id_resolver.conf to shut up logspam #297

Merged
merged 1 commit into from
Jan 20, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions install.sh
Original file line number Diff line number Diff line change
Expand Up @@ -263,6 +263,8 @@ done
for f in libexec_startup/*; do
install_exec "$f" "$DESTDIR$usr_exec_prefix/libexec/startup/$(basename "$f")"
done
install_data misc_etc_files/request-key.d/id_resolver.conf \
"$DESTDIR$sysconfdir/request-key.d/id_resolver.conf"

postinstall
exit
22 changes: 22 additions & 0 deletions misc_etc_files/request-key.d/id_resolver.conf
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# nfs clients of a kernel before 5.15.89.mx64.445 try to use the id_resolver
# for sec=mariux mounts when uid or gid file attributes are transmitted to the
# server (e.g. when chown or chgrp is done).
#
# The kernel nfs clients makes a user space upcall via /sbin/request-key for a
# key of a type id_resolver and a key description like "user:130" or
# "group:125".
#
# As keys of the type id_resolver are not configured in /etc/request-key.conf,
# this will fail but /sbin/request-key logs "request-key: Cannot find command
# to construct key..." to its stdout which ends up in the syslog.
#
# The nfs clients continues by sending the uid/gid value numerically to the nfs
# server, which is what we want.
#
# In this file, we configure a (negative) request-key response for keys of the
# type id_resolver to avoid logfile spam.
#
# Kernels since 5.15.89.mx64.445 don't need that, because the userspace upcall
# is avoided for sec=mariux just the same as it is for sec=sys.

create id_resolver * * /bin/keyctl negate %k 300 %S