Currently, dbus logs commands and their parameters, e.g. from my
system (parts masked out with ##)
Nov  3 13:57:16 samd dbus-daemon[2402]: [session uid=1000 pid=2400] Activating service name='org.a11y.Bus' requested by ':1.3' (uid=1000 pid=9366 comm="java ###")
Nov 13 07:30:37 samd dbus-daemon[577]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.32' (uid=1001 pid=3411 comm="/usr/lib/chromium/chromium --show-component-extens")
Nov 18 12:57:23 samd dbus-daemon[2879]: [session uid=1000 pid=2877] Activating service name='org.kde.ActivityManager' requested by ':1.6' (uid=1000 pid=3231 comm="okular ####")
Nov 21 09:45:13 samd at-spi-bus-launcher[3054]: dbus-daemon[3170]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1001 pid=3098 comm="/usr/bin/kuiserver ")
Nov 22 07:51:39 samd dbus-daemon[2759]: [session uid=1001 pid=2759] Activating via systemd: service name='org.gnome.evince.Daemon' unit='org.gnome.Evince.service' requested by ':1.84' (uid=1001 pid=4154 comm="/usr/bin/evince ####")

The string after service name= varies, typical parameters are
org.a11y.Bus, org.kde.ActivityManager, ca.desrt.dconf,
org.kde.kglobalaccel

Parameter often include file names, e.g. for okular, evince, …

These commands and their parameters do not belong into the system log.
These are private data. Of course, if the system administrator chooses
to spy on a user, he can so so. But by default this should not be the
case.

Consider the typical szenario, where dozens (hundreds) of systems are
operated (like at my job) on Linux systems. The logs might (should) be
aggregated to some server and analysed for malfunction. If this
unnecessary private data is stored there as well, it is a "nice"
target for people wanting to observer the users, very unlikely to get
noticed, not even necessary to leave traces on the machine of the
user.

Additionally:
In some jurisdictions, processing of private data is heavily
regulated, e.g. in Europe with the GDPR. Avoiding logging those
private data makes it much easier for system administrators to be
compliant as well. Otherwiese they would need fancy filters (maybe
logcheck would suffice?) to avoid those data to be stored.

I tagged this security, as I'm not sure if privacy related issues are
treated as security issues as well and in more sensitive environemnts
the need-to-know principle is implemented, meaning that sensitive
information like file names processed should by default not be
disclosed as well, doing so might be security relevant.

I can see the following possible actions, in the order of preference:

1) dbus-daemon does not log this information by default.
   As far as I can see, these messages are useless in normal
   operation. If debugging is required (or problems arise on a
   machine) then of course logging them could be re-enabled.

2) dbus-daemon logs much less by default.
   This would imply at least the removal of the "comm" part, possibly
   unless errors occur. There should be a clear description of how to
   remove the logging altogether as well.

3) Filter sensitive information out of the logging stream.
   Using tools like "logcheck" to filter out those messages. However,
   this can only be a band aid, as administrators would need to
   install additional software, so a good description should be placed
   at a suitable position, and the tool (e.g. logcheck) should be
   recommended by dbus by default, to ensure good coverage.

I'm not sure if logcheck is the right tool, as it by default sends
e-mails an leaves the logs otherwise unaltered, so if centralized
processing happens, logchecking does not interfere.

Please note that ordinary, unprivileged users can see the same information
in /proc, which is where dbus-daemon gets it (dbus-daemon --system runs
as an unprivileged uid that cannot see anything in /proc that ordinary
user accounts can't).

If you don't want other users of the system to see the filenames that
are acted on, you'd already need to take further action, for example
mounting /proc with the hidepid option, which would have the side-effect
of hiding the commands from dbus-daemon too.

The detailed system log is already considered sensitive information,
which is why only the adm group can read it: we can't know what will
end up there.
I'll immediately get this bug report (but possibly phrased in terms of
"the maintainer of this freedesktop crap needs to die in a fire" if I'm
less lucky about who submits the bug):

    Something is starting com.example.Foobard. The log message says
    "requested by :1.23, process 123". This is not enough to know what
    program tried to start com.example.Foobard.

or if the log message isn't present at all:

    Something is silently starting com.example.Foobard and it took me
    hours to find out that it was dbus-daemon. I never asked for this.

The other common source of command names and parameters in the messages
logged by dbus-daemon is when it rejects a message, in which case it
needs to indicate who sent the message.

    smcv

[snip]

I'm with Simon on this issue.

Imho the only sensible thing is to close this bug report and tag it wontfix.

Sorry if this not the outcome you expected.

Regards,
Michael

Hello Simon,

For the running system this is not a problem.

But each program should set sensible defaults for its logging. To
little is of no use but too detailed (by default) is also not correct.

Who needs the details should of course easily be able to turn it on.
I'm not considering taking away options, it is the *default* I'm
discussing. Nowadays it is called "privacy by default" / "security by
default". A dbus developer of course will most likely change it.

Sorry, this I can't follow at all. I'm using Linux for ages, having
strace, pstree, and such be used if needed be. And looking at the very
complex system of processes running nowadays, are there really a
significant amount of people asking these questions while at the same
time not beeing able to turn on a simple configuration option?

I agree for the error case, there the system needs to be more verbose.
Agains, silencing it in the error case is another discussion (which
I'm not advocating), people who need this can surely configure the
system appropriately.

Greetings

          Helge

It seems like there's a potential balance here: logging the command name
(e.g. evince, okular) seems fine, it's the command *parameters* that
represent a potential privacy issue (in the same spirit as "recent
documents").

Yes, comm is readily available to another user or administrator on the
same system at the same time. But that's not the same as being available
to a user or administrator who does not have concurrent access to the
system, as is commonly the case for many single-user systems.

I'm hoping that changing dbus-daemon to only log the command name and
not the arguments would not generate awful bug reports in the other
direction.