[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: DBUS home fouled up
-----BEGIN PGP SIGNED MESSAGE-----
Let me try responding one by one:
> 1) Are the files being written system-level files (pertaining to
> the system-wide invocation of dbus)? Presumably the dbus
> invocations of any user will be in the user's homedir.
yes, we're talking about 'dbus-daemon --system' here.
> 2) You chose db vs run. So are (at least some of) these files
> intended to persist across reboots? If so, that's appropriate. If
> not, they arguably belong in run.
The dbus machine-id is indeed persistent. The pid and system_bus_socket
are as can be expected run-specific and are created by the dbus-daemon
process (NB running as DBUS_USER:DBUS_GROUP).
> 3) I don't understand how "unprivileged" is related to run.
> /var/run and /var/db (on NetBSD) are both root-owned and 755. So
> using them for anything not root involves a subdirectory which is
> created by root and then set to the the non-root user. This seems
> to apply to both run and db. With db, it can be created at
> package install time. With run, it should be done by the rc.d
> script (or smf).
from the filesystem manpage:
> /var/run Temporary files which are not needed across reboots. Only
> root may modify the contents of this directory.
I believe the issue centers around the fact that legacy rc processing is
always done as 'root', but in smf if the user= and group= are specified
non-root they are invoked as such.
Therefore a non-root process has no means to be able to create files or
directories under /var/run without elevated privileges (which is just
Since $DBUS_HOME is statically created with correct owner permissions,
this will *always* work, root or non-privileged.
BTW, thanks to this discussion I notice an anomaly in that
should be fixed to
avoiding problems with differing DBUS_USER values (such as root).
>> 4) Why do you think all dbus things necessarily belong in one of
>> db or run? It seems reasonable that a daemon might have files
>> that are in each category. dbus seems to have a persistent id,
>> a socket, and a pidfile:
For simplicity (when unprivileged) I believe all the files should be
under $DBUS_HOME as indicated above.
If there is violent disagreement, then I guess the smf scripts could
invoke the 'root' user and create the /var/run/dbus directory with
owner DBUS_USER:DBUS_GROUP for the pid and socket file just like the
rc script does, naturally leaving the security question undealt with.
The attached patch does just that, but I'd like to note that this
presumes a 'responsable' daemon program...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
diff --git a/sysutils/dbus/files/smf/dbus.sh b/sysutils/dbus/files/smf/dbus.sh
index 60435df..7a98538 100755
@@ -13,11 +13,16 @@ fi
if [ ! -f @VARBASE@/db/dbus/machine-id ]; then
case "$1" in
- if [ -f @VARBASE@/run/dbus/pid ]; then
- rm -f @VARBASE@/run/dbus/pid
+ if ! [ -d $dir ]; then
+ @MKDIR@ $dir
+ @CHMOD@ 0755 $dir
+ @CHOWN@ @DBUS_USER@:@DBUS_GROUP@ $dir
+ elif [ -f $pidfile ]; then
+ rm -f $pidfile
diff --git a/sysutils/dbus/files/smf/manifest.xml
index 6ef87bf..dc026b0 100644
@@ -19,7 +19,7 @@
- <method_credential user='@DBUS_USER@'
+ <method_credential user='root' group='@DBUS_GROUP@' />
Main Index |
Thread Index |