## which makes
## systemd say the service has failed even though
## everything has completed successfully. So, this
## returns "0" instead which makes systemd say the
## service has succeeded.
This happens a lot. This also makes scripts fail which have set -e or an error trap set. Non-zero exit codes happen. A way to solve it is using || true. Will simplify the code.
Since /lib/systemd/system/hide-hardware-info.service uses DefaultDependencies=no should it also use systemd config option RequiresMountsFor to make sure /proc/cpuinfo /proc/bus /proc/scsi /sys is available?
I don’t see how there will be race conditions. chmod doesn’t change the group permissions.
I did use --recursive originally for chmod but removed it due to the errors in /sys but since that’s fixed now, it can added back although there probably isn’t much benefit since if /sys isn’t accessible, neither are its subdirectories.
The chgrp command is already recursive (that’s the -R flag) since the group needs access to subdirectories.
Thanks. I didn’t know this could be done.
/proc/cpuinfo, /proc/bus and /proc/scsi aren’t mount points (only /proc is). /proc/scsi also isn’t available on debian so it will fail.
The script already sorts this out by checking if they exist and if not gives an error. It doesn’t exit the script though so the error might go unnoticed.
Use sudo if /proc/cpuinfo isn't readable in the start-tor-browser script SSE2
Doesn’t look like it. Still seeing this.
if test -r /proc/cpuinfo && ! grep -q '^flags\s*:.* sse2' /proc/cpuinfo; then
complain "Tor Browser requires a CPU with SSE2 support. Exiting."
exit 1
fi
The opposite. I don’t see any significant attack surface exposed by this and it is necessary for SELinux to properly function. Grsecurity had also whitelisted it from their equivalent feature.