Bug 588745
| Summary: | SELinux is preventing /usr/sbin/NetworkManager "connectto" access on @/tmp/dbus-CtTWWUyXCq. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ritesh Khadgaray <khadgaray> |
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 14 | CC: | dcbw, dwalsh, eparis, justay, mgrepl, mschmidt, raflexras, walters |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | setroubleshoot_trace_hash:ce05e842d0aae4555be8444c5cd16a9703389fc5f822a122e5c98ecf8d4b2992 | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-24 05:09:43 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ritesh Khadgaray
2010-05-04 12:38:30 UTC
I can reproduce this by doing: /etc/init.d/NetworkManager restart but it's not reproducible reliably. It only happens in about 30 % of attempts. Are you seeing this on a Konsole terminal? It is reproducible in any terminal emulator within an X session (I tried gnome-terminal, xterm, konsole). It is not reproducible in plain Linux VT. [...testing...] Alright, I found an important fact. It matters how I exactly I get root. It is reproducible if I use "su". It is not reproducible if I use "su -" or "sudo". Only in the "su" case, the environment contains an item like this: DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-VlC0hYyT6F,guid=94e8ab259a40aaef6e8d776500000058 The name of the abstract socket corresponds to the name reported in the denial message. Colin, Any idea why this would happen? Clearly something in NetworkManager is trying to connect to the session bus. Grepping the upstream source code for DBUS_BUS_SESSION, I only see hits for tests. Dan? (In reply to comment #5) > Clearly something in NetworkManager is trying to connect to the session bus. > Grepping the upstream source code for DBUS_BUS_SESSION, I only see hits for > tests. > > Dan? Nothing in NM should be attempting to connect to the session bus at all... so I'm not quite sure how this could be happening. I suppose I could put some debug tracing in libdbus to break NM when a connection to the session bus is requested? The same thing happens in RHEL-6 (NetworkManager-0.8.0-12.git20100504.el6.x86_64).
In gdb I got a backtrace from NM attempting to connect to the session bus:
Breakpoint 1, connect () at ../sysdeps/unix/syscall-template.S:82
82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Missing separate debuginfos, use: debuginfo-install GConf2-2.28.0-6.el6.x86_64 ORBit2-2.14.17-3.1.el6.x86_64 gamin-0.1.10-9.el6.x86_64 gvfs-1.4.3-7.el6.x86_64
(gdb) bt
#0 connect () at ../sysdeps/unix/syscall-template.S:82
#1 0x000000321622d510 in _dbus_connect_unix_socket (path=0x6e63a0 "/tmp/dbus-5BNaDSui52", abstract=1, error=0x7fffffffd590)
at dbus-sysdeps-unix.c:544
#2 0x0000003216224777 in _dbus_transport_new_for_domain_socket (path=0x6e63a0 "/tmp/dbus-5BNaDSui52", abstract=1,
error=0x7fffffffd590) at dbus-transport-unix.c:81
#3 0x0000003216224934 in _dbus_transport_open_platform_specific (entry=0x6e5310, transport_p=0x7fffffffd5b8,
error=0x7fffffffd590) at dbus-transport-unix.c:161
#4 0x0000003216223031 in _dbus_transport_open (entry=0x6e5310, error=0x7fffffffd640) at dbus-transport.c:376
#5 0x000000321620f931 in connection_try_from_address_entry (address=<value optimized out>, shared=0, error=0x0)
at dbus-connection.c:1733
#6 _dbus_connection_open_internal (address=<value optimized out>, shared=0, error=0x0) at dbus-connection.c:1802
#7 0x000000321620b693 in internal_bus_get (type=DBUS_BUS_SESSION, private=1, error=0x0) at dbus-bus.c:480
#8 0x00007ffff67540c1 in ?? () from /usr/lib64/gio/modules/libgvfsdbus.so
#9 0x0000003212e2c017 in IA__g_type_create_instance (type=<value optimized out>) at gtype.c:1674
#10 0x0000003212e10d9c in g_object_constructor (type=<value optimized out>, n_construct_properties=0, construct_params=0x0)
at gobject.c:1383
#11 0x0000003212e121fa in IA__g_object_newv (object_type=7243776, n_parameters=0, parameters=0x0) at gobject.c:1171
#12 0x0000003212e128ed in IA__g_object_new_valist (object_type=7243776, first_property_name=0x0, var_args=0x7fffffffdb70)
at gobject.c:1323
#13 0x0000003212e12a4c in IA__g_object_new (object_type=7243776, first_property_name=0x0) at gobject.c:1086
#14 0x0000003214259165 in get_default_vfs (arg=<value optimized out>) at gvfs.c:209
#15 0x00000032126604fb in IA__g_once_impl (once=0x32144aa170, func=0x32142590b0 <get_default_vfs>, arg=0x0) at gthread.c:190
#16 0x0000003214226d3e in IA__g_file_new_for_path (path=0x7ffff6d92800 "/etc/sysconfig/network-scripts/") at gfile.c:5743
#17 0x00007ffff6d83989 in setup_ifcfg_monitoring (plugin=0x6bcd80) at plugin.c:369
#18 0x00007ffff6d8451d in get_unmanaged_specs (config=0x6bcd80) at plugin.c:433
#19 0x0000000000470594 in unmanaged_specs_changed (config=<value optimized out>, user_data=<value optimized out>)
at nm-sysconfig-settings.c:322
#20 0x000000000047085b in nm_sysconfig_settings_new (config_file=<value optimized out>, plugins=<value optimized out>,
bus=<value optimized out>, error=0x7fffffffe1a0) at nm-sysconfig-settings.c:1332
#21 0x00000000004450b0 in nm_manager_get (config_file=0x6b1be0 "/etc/NetworkManager/nm-system-settings.conf",
plugins=0x6b4e70 "ifcfg-rh", state_file=0x6b1a30 "/var/lib/NetworkManager/NetworkManager.state", initial_net_enabled=1,
initial_wifi_enabled=1, initial_wwan_enabled=1, error=0x7fffffffe1a0) at nm-manager.c:2956
#22 0x000000000043d915 in main (argc=1, argv=0x7fffffffe328) at main.c:650
Ah hah, it's gvfs. I suppose NM could work around this by doing g_unsetenv("DBUS_SESSION_BUS_ADDRESS"), but...
Anyways, I think the real bug here is that we're still using this broken legacy Unix model where typing "/etc/init.d/NetworkManager restart" is run directly from the admin shell instead of sending a message to Upstart, and thus not inheriting the random environment from the admin shell.
Ritesh you can ignore this for now. Upstream fix is a7e0e6231123b09f717f43ea4064e062b3440223 This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Should be long fixed in 0.8.2 and later. |