Summary: | There are no options to automatically create a socket directory. | ||
---|---|---|---|
Product: | dbus | Reporter: | Aleksey Avdeev <solo> |
Component: | core | Assignee: | D-Bus Maintainers <dbus> |
Status: | RESOLVED MOVED | QA Contact: | D-Bus Maintainers <dbus> |
Severity: | enhancement | ||
Priority: | medium | Keywords: | patch |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Aleksey Avdeev
2016-03-20 14:09:14 UTC
I have prepared a fix in my git (git://git.altlinux.org/people/solo/packages/dbus.git, see http://git.altlinux.org/people/solo/packages/dbus.git): 1. For master -- at branch tmpfiles (see http://git.altlinux.org/people/solo/packages/?p=dbus.git;a=shortlog;h=refs/heads/tmpfiles). 2. For dbus-1.10 -- at branch dbus-1.10-tmpfiles (see http://git.altlinux.org/people/solo/packages/?p=dbus.git;a=shortlog;h=refs/heads/dbus-1.10-tmpfiles). Please explain why this option is needed in the first place. D-Bus has been running fine without it for 11 or 12 years. (In reply to Thiago Macieira from comment #2) > Please explain why this option is needed in the first place. D-Bus has been > running fine without it for 11 or 12 years. The problem only occurs if you use a socket directory Placed on tmpfs. (Moreover, under systemd it is not visible.) I have a problem manifested by sysvinit: when I moved the /var/run on tmpfs when used D-Bus socket /var/run/dbus/system_bus_socket. In other software similar problem, I decided to script uses systemd-tmpfile (systemd-tmpfiles utility works well without systemd), as they were necessary configuration files. But for the D-Bus required configuration files (which stipulates the creation of the directory /var/run/dbus) was not. PS: For a more detailed description of my case, in Russian, there are: https://lists.altlinux.org/pipermail/sysadmins/2016-January/037392.html. Ah, ok. So you're saying that dbus-daemon should mkdir() the directories leading up to the socket path before creating the socket itself? (In reply to Thiago Macieira from comment #4) > Ah, ok. So you're saying that dbus-daemon should mkdir() the directories > leading up to the socket path before creating the socket itself? 1. Such variant may not work with paranoid SELinux settings: D-Bus have been absent are the rights to create the directory. (Since they are not needed for demon, if the required directory already exists). 2. It is unclear how in such cases provide non-standard rights for the created directory. (For example drwxr-x--- root <group>, if access to the D-Bus should have only members of the special group <group>.) (In reply to Aleksey Avdeev from comment #3) > I have a problem manifested by sysvinit If you are using systemd as init, the parent directories are automatically created, so you don't need to do anything: DirectoryMode= If listening on a file system socket or FIFO, the parent directories are automatically created if needed. This option specifies the file system access mode used when creating these directories. Takes an access mode in octal notation. Defaults to 0755. If you are using sysvinit as init, in general you have to write your own init scripts. For example, Debian's /etc/init.d/dbus explicitly creates /var/run/dbus (to hold the pid file, but it's also the right directory to hold the socket), and has done so since at least 2005. I'd reluctantly accept patches for bus/rc.messagebus.in (Slackware) and/or bus/messagebus.in (Red Hat), although I'm not really sure what those distro-specific scripts are doing in our upstream git, and I'm tempted to remove them - particularly if the relevant distributions don't actually use them (if I understand correctly, Red Hat is now 100% systemd, except for some old RHEL releases which use Upstart). bus/messagebus-config (Cygwin) already gets this right. I don't want to solve sysvinit problems by using systemd-tmpfiles, because the distributions that don't use systemd are either doing so because they are sufficiently change-averse or slow-moving that they haven't switched yet (factors which apply equally to systemd-tmpfiles), or because they are deliberately avoiding it for technical or political reasons (in which case they probably want to avoid all things systemd). `mkdir -p` in an init script isn't difficult, and integrating *anything* with sysvinit has so much boilerplate already that one more line makes little difference. (In reply to Aleksey Avdeev from comment #1) > 1. For master -- at branch tmpfiles (see > http://git.altlinux.org/people/solo/packages/?p=dbus.git;a=shortlog;h=refs/ > heads/tmpfiles). This seems like a *lot* of new code to support something (/var/run on tmpfs under sysvinit) that has worked in, for instance, Debian since at least 2005! I'll do a brief review as a follow-up comment. (In reply to Aleksey Avdeev from comment #5) > It is unclear how in such cases provide non-standard rights for the > created directory. (For example drwxr-x--- root <group>, if access to the > D-Bus should have only members of the special group <group>.) This is the first time I've heard of anyone restricting access to the system bus. You can exclude users from the system bus via its XML policy language, if you really need this. Something like this in /etc/dbus-1/system-local.conf should work (untested): <busconfig> <policy context="default"> <deny user="*"/> <allow group="bus-users"/> <allow user="root"/> </policy> </busconfig> Alternatively, systemd-tmpfiles-setup.service already starts before sysinit.target, which starts before sockets that have DefaultDependencies; so a local sysadmin wanting to set permissions can already drop in their own tmpfiles snippet without any help from us. Review: We would prefer to receive patches as attachments to this Bugzilla in unified diff format, preferably from `git format-patch`. > Description=D-Bus System Message Bus Socket >+Wants=systemd-tmpfiles-setup.service >+After=systemd-tmpfiles-setup.service This is unnecessary. dbus.socket has the DefaultDependencies, which include sysinit.target, which depends on systemd-tmpfiles-setup.service. The DefaultDependencies are provided by systemd exactly so that normal, non-early-boot services (like dbus) do not have to declare dependencies on specific details of early boot: instead, they can assume that a normal system is up. > Description=D-Bus User Message Bus Socket >+Wants=systemd-tmpfiles-setup.service >+After=systemd-tmpfiles-setup.service This is unnecessary. `systemd --user` is started by systemd-logind, which starts after dbus.socket, so we know tmpfiles setup has already been done. Also, there is no per-user systemd-tmpfiles-setup.service in /usr/lib/systemd/user, so this dependency is not satisfied anyway. > +if test -n "$DBUS_SESSION_SOCKET_DIR" && echo "$DBUS_SESSION_SOCKET_DIR" | grep -q '^/'; then >+ SYSTEMD_TMPFILES_DBUS_SESSION_SOCKET_DIR="d $DBUS_SESSION_SOCKET_DIR 1777 root root -" The default for DBUS_SESSION_SOCKET_DIR is in /tmp, which doesn't need creating. The default behaviour of dbus-daemon on Linux is to use Unix sockets in the abstract namespace, which are opaque tokens that do not have path-like behaviour, so creating their "directory" is meaningless. > +DBUS_SYSTEM_SOCKET_DIR=`echo "$DBUS_SYSTEM_SOCKET" | sed -rn 's@^[[^/]]+$@.@p;s@^/+[[^/]]*$@/@p;s@^(/*.*[[^/]])/+[[^/]]*$@\1@p'` That's an intimidatingly long line. What does it do that DBUS_SYSTEM_SOCKET_DIR="${DBUS_SYSTEM_SOCKET%/*}" wouldn't? > +AC_DEFINE_UNQUOTED(DBUS_SYSTEM_SOCKET_DIR,"$DBUS_SYSTEM_SOCKET_DIR",[The name of the socket the system bus listens on by default]) The documentation doesn't match the implementation. General configure.ac points: - prefer to use AS_IF instead of if/fi in new m4sh code (one day I'll fix the current if/fi) - lots of things are underquoted (use one level of [] per level of ()) (In reply to Aleksey Avdeev from comment #3) > PS: For a more detailed description of my case, in Russian, there are: > https://lists.altlinux.org/pipermail/sysadmins/2016-January/037392.html. Sorry, I don't think my 3-word Russian vocabulary is going to get me very far with that... If what I've suggested here is not sufficient for some reason, please summarize the situation in the commit message of your proposed change? Since the Altlinux patch seems to be using the "Red Hat" init script bus/messagebus.in (?), I think all the tmpfiles complexity you've introduced could be replaced by this (not actually a patch but hopefully you get the idea): --- messagebus.in +++ messagebus.in ... +DBUS_SYSTEM_SOCKET="@DBUS_SYSTEM_SOCKET@" +mkdir -m755 -p "${DBUS_SYSTEM_SOCKET%/*}" ... -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/148. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.