Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 706100

Summary: sys-apps/dbus-1.12.16 leaks command-line arguments into system logs
Product: Gentoo Linux Reporter: Anon Emuss <abuslbea>
Component: Current packagesAssignee: Freedesktop bugs <freedesktop-bugs>
Status: RESOLVED UPSTREAM    
Severity: normal    
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914799
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Patch for dbus adding option (disabled by default) for not logging command-line arguments
Patch for dbus ebuild to apply dbus patch and conditionally enable configure options

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.