[GH-ISSUE #266] Using systemd-resolved causes DNS to not work #188

Closed
opened 2026-05-05 05:16:47 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @kalegrill on GitHub (Jan 28, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/266

I haven't debugged this too much, but I noticed if /etc/nsswitch.conf is set with "resolve" instead of "dns" as per nss-resolve(8), then in firejail an inaccessible file is attempted to be read (/sys/fs/kdbus/0-system/bus gets an EACCES) and names are not resolved. This is regardless of if systemd-resolved is active, it only needs to be configured in /etc/nsswitch.conf.

Originally created by @kalegrill on GitHub (Jan 28, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/266 I haven't debugged this too much, but I noticed if /etc/nsswitch.conf is set with "resolve" instead of "dns" as per [nss-resolve(8)](http://www.freedesktop.org/software/systemd/man/nss-resolve.html), then in firejail an inaccessible file is attempted to be read (/sys/fs/kdbus/0-system/bus gets an EACCES) and names are not resolved. This is regardless of if systemd-resolved is active, it only needs to be configured in /etc/nsswitch.conf.
gitea-mirror 2026-05-05 05:16:47 -06:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@kalegrill commented on GitHub (Feb 2, 2016):

Some tests:
Curl run outside firejail, resolved active or inactive, nsswitch with or without "dns" after "resolve": DNS works.
Curl run inside firejail, resolved active or inactive, nsswitch without "dns": DNS doesn't work.
Curl run inside firejail, resolved active or inactive, nsswitch with "dns" after "resolve": DNS works.

I haven't looked into how exactly this works, but evidently outside of firejail nss-resolve failsover correctly even without the "dns" entry in nsswitch; however, inside firejail it does not failover without "dns" included.

The example in the nss-resolve(8) lacks the "dns" option yet claims that "nss-resolve will chain-load nss-dns if systemd-resolved.service is not running". From my brief look that seems to be the case when the return for /sys/fs/kdbus/0-system/bus is ENOENT but not when it is EACCES. This doesn't look like a firejail issue to me?

The easy fix if one wants to use systemd-resolved outside of firejail is to put dns after resolve on the hosts line in nsswitch.conf. I should have been doing that in the first place.

<!-- gh-comment-id:178340088 --> @kalegrill commented on GitHub (Feb 2, 2016): Some tests: Curl run outside firejail, resolved active or inactive, nsswitch with or without "dns" after "resolve": DNS works. Curl run inside firejail, resolved active or inactive, nsswitch without "dns": DNS doesn't work. Curl run inside firejail, resolved active or inactive, nsswitch with "dns" after "resolve": DNS works. I haven't looked into how exactly this works, but evidently outside of firejail nss-resolve failsover correctly even without the "dns" entry in nsswitch; however, inside firejail it does not failover without "dns" included. The example in the nss-resolve(8) lacks the "dns" option yet claims that "nss-resolve will chain-load nss-dns if systemd-resolved.service is not running". From my brief look that seems to be the case when the return for /sys/fs/kdbus/0-system/bus is ENOENT but not when it is EACCES. This doesn't look like a firejail issue to me? The easy fix if one wants to use systemd-resolved outside of firejail is to put dns after resolve on the hosts line in nsswitch.conf. I should have been doing that in the first place.
Author
Owner

@netblue30 commented on GitHub (Feb 6, 2016):

Thanks for the hint. I'll do a test here and I'll have something in the next release.

<!-- gh-comment-id:180775216 --> @netblue30 commented on GitHub (Feb 6, 2016): Thanks for the hint. I'll do a test here and I'll have something in the next release.
Author
Owner

@netblue30 commented on GitHub (Jun 1, 2016):

Try version 0.9.40, it has lots of fixes. If you still see the problem, let me know and I'll reopen the bug.

<!-- gh-comment-id:223008542 --> @netblue30 commented on GitHub (Jun 1, 2016): Try version 0.9.40, it has lots of fixes. If you still see the problem, let me know and I'll reopen the bug.
Author
Owner

@aineko commented on GitHub (Aug 9, 2017):

I am observing the same issue on version 0.9.48 when trying to access zeroconf-discovered hosts.

If I compare
$ strace /usr/bin/ping some_intranet_host
and
$ /usr/bin/firejail --noprofile --allow-debuggers strace /usr/bin/ping some_intranet_host
I can clearly see that nss-resolve abandons resolution when it gets EACCES instead of ENOENT for /sys/fs/kdbus/0-system/bus

Unblacklisting /sys/fs makes the nss-resolve get ENOENT for /sys/fs/kdbus/0-system/bus and then continue by opening /var/run/dbus/system_bus_socket which succeeds:
$ /usr/bin/firejail --noprofile --noblacklist=/sys/fs /usr/bin/ping some_intranet_host

Still looks like the proper way to fix this is on nss-resolve side. Opened an issue there.

<!-- gh-comment-id:321404522 --> @aineko commented on GitHub (Aug 9, 2017): I am observing the same issue on version 0.9.48 when trying to access zeroconf-discovered hosts. If I compare $ strace /usr/bin/ping some_intranet_host and $ /usr/bin/firejail --noprofile --allow-debuggers strace /usr/bin/ping some_intranet_host I can clearly see that nss-resolve abandons resolution when it gets EACCES instead of ENOENT for /sys/fs/kdbus/0-system/bus Unblacklisting /sys/fs makes the nss-resolve get ENOENT for /sys/fs/kdbus/0-system/bus and then continue by opening /var/run/dbus/system_bus_socket which succeeds: $ /usr/bin/firejail --noprofile --noblacklist=/sys/fs /usr/bin/ping some_intranet_host Still looks like the proper way to fix this is on nss-resolve side. Opened an [issue](https://github.com/systemd/systemd/issues/6586) there.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#188
No description provided.