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/> References: <bug-252094-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252094 --- 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 re= use 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 datab= ase code doesn't appear to have this bug. I don't love the idea of opening the db each time. For the sake of sandbox= ing frameworks like Capsicum where arbitrary filesystem accesses are prohibited= , it would be nicer if the setgroupent(3) interface behaves as documented. Sinc= e 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 rou= te to fixing the original problem. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252094-227-8NrOpkfiRo>