Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 706100 - sys-apps/dbus-1.12.16 leaks command-line arguments into system logs
Summary: sys-apps/dbus-1.12.16 leaks command-line arguments into system logs
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Freedesktop bugs
URL: https://bugs.debian.org/cgi-bin/bugre...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-22 15:20 UTC by Anon Emuss
Modified: 2020-02-02 22:02 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch for dbus adding option (disabled by default) for not logging command-line arguments (dbus-option-hide-arguments.patch,3.77 KB, patch)
2020-01-22 15:32 UTC, Anon Emuss
Details | Diff
Patch for dbus ebuild to apply dbus patch and conditionally enable configure options (dbus-1.12.16.ebuild.patch,1021 bytes, patch)
2020-01-22 15:35 UTC, Anon Emuss
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anon Emuss 2020-01-22 15:20:41 UTC
dbus records entire command-lines into the system logs.  For example, if I view a PDF with evince, the system log will contain a line like this:
  Jan 21 12:34:56 [dbus-daemon] [session uid=1234 pid=1234] Activating service name='org.service' requested by ':0.0' (uid=1234 pid=1235 comm="evince filename.pdf ")
This seems like an unnecessary (albeit minor) privacy violation (particularly the filename included in the above example).  I could not find any Gentoo bugs related to this, but I did find that somebody had filed a bug upstream:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914799
The maintainers appear to feel that this is necessary for debugging and would rather not fix it.  They correctly point out that anybody recording ps output could have access to the same information.  I agree with the submitter that this behavior should be enabled only on developer systems, but it sounds like the developers are not too keen on changing it.  I developed a patch for my system, which I will attach below, and would appreciate knowing if anybody here thinks it is worth trying to submit it upstream (or if anybody wants to try submitting it upstream themselves).

Reproducible: Always

Steps to Reproduce:
1.  Run command that uses dbus.
2.  Command, along with all arguments, is recorded in the system log.
Actual Results:  
Command-line arguments are recorded in the system log.

Expected Results:  
Command is not recorded in the system logs, or at least not the command-line arguments.
Comment 1 Anon Emuss 2020-01-22 15:32:03 UTC
Created attachment 603954 [details, diff]
Patch for dbus adding option (disabled by default) for not logging command-line arguments

This is my proposed patch for dbus.  It adds two new configure options.  One option switches from using the /proc/<pid>/cmdline file to using the /proc/<pid>/comm file when recording the command, which has much less information in it.  This seems to be a little severe, as the command is frequently truncated.  The second option only records the command-line up to the end of the command itself, truncating any arguments.

Both of these options are disabled by default, so installing this patch should not affect the system.  I then patched the ebuild so it enables one of these options, unless the debug USE flag is set.  That way, somebody can restore the original behavior by changing a USE flag.  The developers think that behavior is useful for debugging, so the debug USE flag seems appropriate.
Comment 2 Anon Emuss 2020-01-22 15:35:56 UTC
Created attachment 603956 [details, diff]
Patch for dbus ebuild to apply dbus patch and conditionally enable configure options

This is the ebuild patch mentioned in the comment for the dbus patch.  It applies the dbus patch and, unless the debug USE flag is set, enables one of the options added by the patch so that dbus will record the command name, but not its arguments.
Comment 3 Mike Gilbert gentoo-dev 2020-01-22 16:02:34 UTC
I don't want to carry this as a distro-specific patch.

If you can convince upstream to merge it, we can wire up the ebuild appropriately.
Comment 4 Anon Emuss 2020-02-02 21:41:34 UTC
(In reply to Mike Gilbert from comment #3)
> I don't want to carry this as a distro-specific patch.
> 
> If you can convince upstream to merge it, we can wire up the ebuild
> appropriately.

That is reasonable.  I am having trouble with upstream, so it might be best to just close this bug, and I can open again if I get it accepted.  If not, I am fine maintaining my own private patch.

Thanks for responding.