Skip to content

lib/pam_pass_non_interactive.c, src/{chfn,chsh,newgrp,passwd}.c: Don't log user-provided strings#1627

Open
alejandro-colomar wants to merge 1 commit into
shadow-maint:masterfrom
alejandro-colomar:regression
Open

lib/pam_pass_non_interactive.c, src/{chfn,chsh,newgrp,passwd}.c: Don't log user-provided strings#1627
alejandro-colomar wants to merge 1 commit into
shadow-maint:masterfrom
alejandro-colomar:regression

Conversation

@alejandro-colomar
Copy link
Copy Markdown
Collaborator

@alejandro-colomar alejandro-colomar commented May 19, 2026

A few years ago, we started validating these strings as user or group names, which made them safe to log. However, these strings may be more than just a simple local user or group name. They may be fully qualified names, which don't pass the validation.

This patch reverts the old one, and so we don't validate the strings anymore. Instead, let's not trust those strings, and thus don't log them. In some cases, we can log the UID or GID, which could be similarly useful. In others, we don't have that information, so just remove the string; that's less informative, but it's as much as we can do safely.

Fixes: 326889c (2024-10-22; "Fix coverity unbound buffer issues")
Closes: #1626
Reported-by: @nooreldeenmansour
Cc: @MarcinDigitic
Cc: @ikerexxe


Please be very skeptic when reviewing this patch. I'm less comfortable than usually. I believe the changes from username/groupname to uid/gid are good, but please revise. Also, I've removed much information, especially from the audit log. Please check that this is okay.


The regression affects all versions since (and including) 4.17.0.

…t log user-provided strings

A few years ago, we started validating these strings as user or group
names, which made them safe to log.  However, these strings may be more
than just a simple local user or group name.  They may be fully
qualified names, which don't pass the validation.

This patch reverts the old one, and so we don't validate the strings
anymore.  Instead, let's not trust those strings, and thus don't log
them.  In some cases, we can log the UID or GID, which could be
similarly useful.  In others, we don't have that information, so just
remove the string; that's less informative, but it's as much as we can
do safely.

Fixes: 326889c (2024-10-22; "Fix coverity unbound buffer issues")
Closes: <shadow-maint#1626>
Reported-by: Noor Eldeen Mansour <nooreldeen.mansour@canonical.com>
Cc: Marcin Nowakowski <marcin.w.nowakowski@gmail.com>
Cc: Iker Pedrosa <ipedrosa@redhat.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Comment thread src/newgrp.c
"Failed to crypt password with previous salt of group '%s'",
groupname);
"Failed to crypt password with previous salt of group %ju",
(uintmax_t) grp->gr_gid);
Copy link
Copy Markdown
Collaborator Author

@alejandro-colomar alejandro-colomar May 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/etc/group (which is what getgrnam(3) reads) is world-readable. How is this supposed to be sensitive?

Comment thread src/newgrp.c Dismissed
Comment thread src/newgrp.c Dismissed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

passwd does not accept fully qualified usernames (user@domain)

2 participants