Bug 1651000 - "pacmd list" output contains confidential information (user, host, and machine_id)
Summary: "pacmd list" output contains confidential information (user, host, and machin...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-18 16:29 UTC by Steve
Modified: 2020-05-26 18:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-26 18:26:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Steve 2018-11-18 16:29:45 UTC
Description of problem:
The "pacmd list" output contains useful diagnostic info, but it also contains confidential info that compromises user privacy. That makes it unethical to ask users to attach the output to a bug report.

Here are the confidential fields (with values obfuscated):

$ pacmd list | egrep '(user|host|machine_id) =' | sort -u
		application.process.host = "xxxxx"
		application.process.machine_id = "00000000000000000000000000000000"
		application.process.user = "yyyyy"

Version-Release number of selected component (if applicable):
pulseaudio-utils-12.2-1.fc29.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. $ pacmd list

Actual results:
The output contains the user, host, and machine_id.

Expected results:
The output protects user privacy by obfuscating the values of the user, host, and machine_id fields.

Additional info:
See these bugs for actual examples:

Bug 1648780 - no analog output device with F29 Workstation Live
Bug 1650889 - Headset microphone not detected on CS4208

Comment 1 Steve 2018-11-18 16:31:34 UTC
There is no "Privacy" keyword, so add the "Security" keyword.

Comment 2 Wim Taymans 2019-09-27 10:49:16 UTC
How is this supposed to work?

If the fields are obfuscated there is not much point in showing them at all, which is not
useful when you want to know who's running the application and where.

Do you suggest to add a special option like --privacy especially for bug reports that filters
out sensitive fields? How do other projects do this?

Comment 3 Ben Cotton 2019-10-31 18:48:27 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Ben Cotton 2019-11-27 23:29:03 UTC
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 5 Steve 2020-03-11 03:35:05 UTC
Reopening against F30:

pulseaudio-utils-12.2-9.fc30.x86_64

(In reply to Wim Taymans from comment #2)
> How is this supposed to work?
> 
> If the fields are obfuscated there is not much point in showing them at all,
> which is not useful when you want to know who's running the application and where.

What is a realistic use-case? Is that info for debugging or for end users?

> Do you suggest to add a special option like --privacy especially for bug reports that filters out sensitive fields?

I would suggest making privacy the default and adding a "--verbose" option so that a user can display confidential info if needed.

> How do other projects do this?

The ABRT "gnome-abrt" tool and the SELinux "sealert" tool automatically obfuscate certain info. Both can be found under the "System" menu item.

Comment 6 Steve 2020-03-11 03:47:09 UTC
Here is an example from a bug report against selinux-policy.

selinux puts the string "(removed)" in certain fields. For example:

Host                          (removed)

Platform                      Linux (removed) 5.6.0-0.rc4.git0.1.fc33.x86_64 #1 ...

Bug 1812165 - SELinux is preventing firewalld from using the 'sys_nice' capabilities. 
https://bugzilla.redhat.com/show_bug.cgi?id=1812165

Comment 7 Steve 2020-03-11 04:03:38 UTC
(In reply to Steve from comment #5)
...
> The ABRT "gnome-abrt" tool ... automatically obfuscate[s] certain info. ...

That's no longer exactly true. "gnome-abrt" is a GUI app that lets users search and edit files and then choose which files to actually include in the bug report. That's WAY more than what is needed for the "pacmd" command-line tool. :-)

However, you can see an example of what information can be leaked by a user in this bug report, which has the "environ" file attached:

Bug 1808450 - [abrt] gnome-shell: wl_resource_get_version(): gnome-shell killed by SIGSEGV

Comment 8 Steve 2020-03-12 20:15:47 UTC
Another example:

The "--no-hostname" option to "journalctl" suppresses the display of the hostname:

$ journalctl -b --no-hostname -g 'DMI:'
-- Logs begin at Mon 2019-06-17 17:30:08 BST, end at Thu 2020-03-12 19:01:20 GMT. --
Mar 12 13:47:40 kernel: DMI: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.5.1 08/09/2018

That's from Bug 1812055, Comment 3.

Comment 9 Ben Cotton 2020-04-30 20:21:13 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 10 Ben Cotton 2020-05-26 18:26:50 UTC
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.