security & privacy: do not collect all output from journalctl & syslog

[cstockton]

I reported this some months ago to customer support when I tried to get support for my ongoing system lockups with the CPU fan pinned at full when closing the lid, resolved only by a power cycle. These are still occurring but I've decided to just shut down my laptop when not in use, hoping it's resolved some point in the future. There may be additional context for this issue in my ticket history if you wish to look it up.

Issue/Bug Description:
The system76 drivers bug reporting collects the log output of all the users system services and full syslog output.

system76-driver/system76driver/util.py

Line 53 in 34c87f2

SubProcess.check_call(['journalctl', '--since', 'yesterday'], stdout=fp)

- These are generated without user consent, but only uploaded after confirmation based on what I see in:

system76-driver/system76driver/gtk.py

Line 162 in 34c87f2

tgz = create_logs(self.args.home)

My issues with this practice are:

1. Security - It appears the files are copied to the home directory using default permissions that would make them world readable, based on that gtk message. This means that low privileged users (not in the systemd-journal) for journal, users without (syslog or adm) membership for syslog can get full journal & syslog access leaking potential configuration details. I understand on a workstation this is less of a concern than a server environment, but they should still be taken into consideration and be violated only with necessity.

2. Privacy - While they are not automatically uploaded, not all users may understand how wide reaching the report may be. If they are frustrated or in a rush to get their system working they may not bother trying to audit the contents. These files may contain very personal information, PII data, it's impossible to assert with absolute certainty that PKI, PCI, or any other strictly regulated data may not end up in these files on a developers machine.

Steps to reproduce (if you know):
Look at source control.

Expected behavior:
System76 does not collect all system information by default, instead maintains a whitelist of very granular rules constrained by [systemd unit, pattern] known to be useful for diagnosis. This negates both security and privacy concerns. I don't think there is any other option.

[mlncn]

This would also help protect support technicians from being overwhelmed/distracted by unrelated notices and errors in the logs. (Also have experienced the described system lockup but not often and not for a while.)

[cstockton]

What OS do you run @mlncn? I haven't used my laptop except a handful of times for troubleshooting it since I bought it due to the full system lockups that occur very often when closing the laptop lid or when 1/6 times or so when just shutting down. I've tried a minimal lubuntu install, popos and ubuntu. It definitely occurred the most on ubuntu.

Support told me there was no other reported issues, then I achieved a small victory thinking the problem went away when it shutdown successfully multiple times in a row one day after some updates. But sure enough the first day I actually tried to use it to write a code it locked up after closing the lid after a coding session. At this point I wouldn't mind a known working configuration, i.e. OS and if you use the systemd firmware or not I had some suspicions over the fact I saw some system76 firmware msgs that had a "stopping" message without a corresponding "stopped"shutdown. Thanks!

[mlncn]

@cstockton do we have a separate bug report for this? :-) Feel bad taking over this one. I'm on PopOS and latest firmware on a 2018 Oryx Pro.

Here's my bug report from early March, "Second time in a row that it has crashed rather than suspend when lid closed":

Symptom: Close lid (configured to suspend on lid close) and some seconds after that the fan goes crazy and runs at top speed for 5+ minutes, and then the computer shuts off.

One difference recently is using an external monitor and so having switched to NVIDIA graphics mode— i have definitely, separately, had the computer crash after unplugging the external monitor while the computer was asleep. But the most recent time, for which the logs generated after starting the computer back up again are attached, the mode had already been switched to Intel and the computer restarted intentionally, before this problem reoccurred.

I have found in general it seems more stable in Intel graphics mode, and am in that mode 95% of the time because i don't happen to have an external monitor at the moment. Was in NVIDIA mode for about a week and did not have this problem (did spontaneously shut off twice though). If i did have an external monitor and experienced these problems more often i suspect i'd be even more upset with System76 right now.

[ahoneybun]

@cstockton was this with the latest firmware as well?