- it sounds like we're going to modify the ../local/.. version of the file in a package update. I think this is a mistake. If we're going to modify policy, we should modify the 'real' policy and leave the ../local/.. version for the system administrator.
- it sounds like the rule we're adding a very broad rule that allows far more access than needed for the problem at hand. Reducing this to just allowing necessary privileges on the '@userdb-*' sockets would be much tighter.
- based on the fact that these interfaces look like they're part of systemd, it probably solves a lot more problems to add these rules to abstractions/nameservice near the existing systemd rules, or perhaps move those and add this to a new abstraction, and add it to the abstractions/nameservice file. That would address this same service when used via other applications, not just libvirt.
Funny thing though, I only see this userdb- string in our packaging: userdb_thread_sockaddr in:
systemd_245.4-4ubuntu3.4/src/shared/userdb.c
systemd_245.4-4ubuntu3.3/src/shared/userdb.c
systemd_245.2-1ubuntu1/src/shared/userdb.c
systemd_245.5-3ubuntu1/src/shared/userdb.c
systemd_245.4-4ubuntu3/src/shared/userdb.c
systemd_245.4-4ubuntu3.2/src/shared/userdb.c
systemd_245.4-2ubuntu1/src/shared/userdb.c
systemd_245.4-4ubuntu3.5/src/shared/userdb.c
systemd_245.5-2ubuntu2/src/shared/userdb.c
systemd_245.4-4ubuntu1/src/shared/userdb.c
systemd_245.4-4ubuntu3.6/src/shared/userdb.c
systemd_245.4-4ubuntu3.1/src/shared/userdb.c
systemd_245.6-1ubuntu1/src/shared/userdb.c
I can't find this code via Debian Code Search, eg:
Hello Christian, a few thoughts:
- it sounds like we're going to modify the ../local/.. version of the file in a package update. I think this is a mistake. If we're going to modify policy, we should modify the 'real' policy and leave the ../local/.. version for the system administrator.
- it sounds like the rule we're adding a very broad rule that allows far more access than needed for the problem at hand. Reducing this to just allowing necessary privileges on the '@userdb-*' sockets would be much tighter.
- based on the fact that these interfaces look like they're part of systemd, it probably solves a lot more problems to add these rules to abstractions/ nameservice near the existing systemd rules, or perhaps move those and add this to a new abstraction, and add it to the abstractions/ nameservice file. That would address this same service when used via other applications, not just libvirt.
Funny thing though, I only see this userdb- string in our packaging: userdb_ thread_ sockaddr in: 245.4-4ubuntu3. 4/src/shared/ userdb. c 245.4-4ubuntu3. 3/src/shared/ userdb. c 245.2-1ubuntu1/ src/shared/ userdb. c 245.5-3ubuntu1/ src/shared/ userdb. c 245.4-4ubuntu3/ src/shared/ userdb. c 245.4-4ubuntu3. 2/src/shared/ userdb. c 245.4-2ubuntu1/ src/shared/ userdb. c 245.4-4ubuntu3. 5/src/shared/ userdb. c 245.5-2ubuntu2/ src/shared/ userdb. c 245.4-4ubuntu1/ src/shared/ userdb. c 245.4-4ubuntu3. 6/src/shared/ userdb. c 245.4-4ubuntu3. 1/src/shared/ userdb. c 245.6-1ubuntu1/ src/shared/ userdb. c
systemd_
systemd_
systemd_
systemd_
systemd_
systemd_
systemd_
systemd_
systemd_
systemd_
systemd_
systemd_
systemd_
I can't find this code via Debian Code Search, eg:
http:// codesearch. debian. net/search? q=userdb- %25016 codesearch. debian. net/search? q=ret_salen% 20%3D%20offseto f codesearch. debian. net/search? q=NSS%20emulati on
http://
http://
I've also tried looking in userdb.c manually: /sources. debian. org/src/ systemd/ 247.3-3/ src/shared/ userdb. c/
https:/
'sock' only shows up in a header file, "socket-util.h"
It sure looks like it still exists but it's much harder to find in newer packages.
Thanks