Date: Fri, 08 Jan 2021 21:35:42 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 252094] nss "compat": getpw(nam|uid)_r(3) inadvertently reset next entry key for getpwent_r(3) Message-ID: <bug-252094-227-8NrOpkfiRo@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-252094-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252094 --- Comment #4 from Mark Johnston <markj@FreeBSD.org> --- Sorry for the delay. I think the passwd patch is ok, I will queue it up for commit. With respect to getgrnam_r() and getgrgid_r(), I note that we have this "stayopen" whose purpose seems to be exactly to allow those functions to reuse a database handle. But files_setgrent() and compat_setgrent() never set st->stayopen, so as far as I can tell they will either always open and close the db (unless a previous getgrent() call had opened the db). The pw database code doesn't appear to have this bug. I don't love the idea of opening the db each time. For the sake of sandboxing frameworks like Capsicum where arbitrary filesystem accesses are prohibited, it would be nicer if the setgroupent(3) interface behaves as documented. Since it doesn't, it's hard to argue against simply opening and closing the group db each time getgr(nam|gid)() is called, especially since that's an easier route to fixing the original problem. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252094-227-8NrOpkfiRo>