On Sun, 29 Jan 2023, Kang-Che Sung wrote:
> +IF_FEATURE_FIND_NOUSER( ACTS(nouser))
> +IF_FEATURE_FIND_NOUSER( ACTS(nogroup))
Typo. (Should be IF_FEATURE_FIND_NOGROUP)
Thanks!
> +ACTF(nouser)
> +{
> + return !getpwuid(statbuf->st_uid);
> +}
I think there is a logic hole here.
getpwuid may return a NULL pointer on an error that's not "UID not found in
database".
Although your logic written like this conforms to POSIX, I don't know
whether in practice this would bring in security risk.
> +#endif
> +#if ENABLE_FEATURE_FIND_NOGROUP
> +ACTF(nogroup)
> +{
> + return !getgrgid(statbuf->st_gid);
> +}
Same problem as above (getgrgid may return NULL on an error other than "not
found")
This may not persuade you, but other implementations do the same:
https://git.savannah.gnu.org/cgit/findutils.git/tree/find/pred.c#n671
https://cgit.freebsd.org/src/tree/usr.bin/find/function.c#n1255
https://github.com/kofemann/opensolaris/blob/master/usr/src/cmd/find/find.c#L953
A scenario I can imagine is a system with a periodic find job that deletes
all -nouser files. Say that something (an adversary?) exhausts
system resources. Now getpwuid() always returns NULL (ENFILE, ENOMEM)
and now all files are deleted. I would conclude that -nouser is
imperfectly reliable (as it inherits subsystem reliability), and that users
of find should take that into consideration.
That said, the lack of error messages was an important part of this
unresolved tale: https://bugzilla.redhat.com/show_bug.cgi?id=847878
They ended up suggesting ltrace. Even so, I don't think error logging
for getpwuid/getgrgid in find is needed in busybox, which is looking to
stay slim.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
