summaryrefslogtreecommitdiffstats
path: root/config/chroot_local-includes/lib
Commit message (Collapse)AuthorAgeFilesLines
* Don't start tails-shutdown-on-media-removal.service with toram (#17800)sajolida2020-07-131-0/+1
|
* tails-gdm-failed-to-start: move to python scriptboyska2020-07-101-8/+1
|
* ref #17533 newlines in error message!boyska2020-07-101-8/+10
| | | | a message which is easier to read is more likely to give useful bug reports
* ref #17533 fix possible overflowboyska2020-07-101-1/+1
| | | | | | | plymouth has stringent limits on message-length. The previous method of trimming the message was only appropriate for single-line messages. Now it's always valid. This is important because messages exceeding length would result in no message at all.
* Add Greeter option to enable the Unsafe Browser (refs: #17085)segfault2020-06-181-11/+0
| | | | ... and disable it by default.
* Greeter: Move settings files to /var/lib/gdm3/settings (refs: #17136)segfault2020-06-181-3/+3
| | | | To make it easier to persist all of these settings.
* Give tails-remove-overlayfs-dirs.service more time to do its job (refs: #17278)intrigeri2020-05-141-0/+7
| | | | | | We currently set DefaultTimeoutStopSec=5s. I assume that in most cases, deleting overlayfs directories from memory should be super fast, but I'd rather not bet on this for security matters.
* Give tails-synchronize-data-to-new-persistent-volume-on-shutdown.service ↵intrigeri2020-05-141-0/+9
| | | | | | | | | | | | | | | | more time to do its job (refs: #17278) We currently set DefaultTimeoutStopSec=5s, which means copying just the APT lists (215MB currently), not even taking into account the actual additional packages installed by the user, would need to happen at no less than 43MB/s for the ExecStop= to succeed. Most real-world bare metal USB sticks don't provide anything close to this write rate. I can't reproduce the problems caused by this bug when running the test suite on my laptop, but it does happen regularly on lizard: even virtual USB stick backed by tmpfs are not always fast enough there.
* sync(1) the persistent volume after copying APT data to it (refs: #17278)intrigeri2020-05-141-1/+2
| | | | | | | | | | | | | | I've observed cases when that service started, copied part of the data, but after the next boot: - Not all the data can be found on the persistent volume. - The flag file that indicates that this service has finished its job is not present. At this point I don't know whether this service was killed before it could finish its job, or this service did copy the data but it was not sync'ed to disk. Let's eliminate the second possibility and make it easier to reason on this problem.
* Create flag file for debugging (refs: #17278)intrigeri2020-05-141-1/+3
| | | | | I guess we could revert this commit once we're confident we have fixed the main bugs in this area.
* Point to the corresponding design docintrigeri2020-03-201-0/+1
|
* Merge remote-tracking branch 'origin/stable' into ↵intrigeri2020-01-142-3/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | feature/8415-overlayfs+force-all-tests The stable branch got upgraded to the "single SquashFS diff" scheme (#15281), so we'll need the corresponding v2 UDFs and IUKs. As part of the conflict resolution, I'm therefore referencing them in the test suite, even though: - I did not create nor upload these IUKs yet. - I did not generate the corresponding UDFs and their signatures. My goal here is to have the test suite reflect what we should test nowadays, and fail in a more meaningful way.
| * Avoid 2 minutes delay while rebooting after applying an automatic upgrade ↵intrigeri2020-01-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (refs: #17026) Otherwise, for some reason user@1000.service can't be stopped while rebooting after applying an upgrade until the default 2 minutes timeout is reached: A stop job is running for User Manager for UID 1000 (x / 2 min) I suspect that's because the Upgrader is running via sudo as another user, so the amnesia user's systemd instance is not allowed to kill it and as a result, the entire session is left in running state. OTOH this problem does not happen when the persistence setup wizard or the Unsafe Brower is left running before rebooting; that's perhaps because they don't run as systemd units.
| * Upgrader: refresh the signing key before checking for available upgrades ↵intrigeri2019-12-241-1/+2
| | | | | | | | (refs: #15279)
| * Move the Upgrader's trusted keyring to tails-upgrade-frontend's $HOME and ↵intrigeri2019-12-231-3/+2
| | | | | | | | | | | | | | make it writable by that user (refs: #15279) This will be needed in order to refresh our signing key before checking for upgrades.
* | Merge remote-tracking branch 'origin/stable' into ↵intrigeri2019-12-171-1/+1
|\ \ | |/ | | | | feature/8415-overlayfs+force-all-tests
| * Merge remote-tracking branch 'origin/stable' into ↵intrigeri2019-12-133-5/+3
| |\ | | | | | | | | | bugfix/17166-fix-unknown-escape-sequence
| * | Fix escape sequence in tails-gdm-failed-to-start.service (refs: #17166)segfault2019-10-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The command works, but produces this message: /lib/systemd/system/tails-gdm-failed-to-start.service:11: Ignoring unknown escape sequences: "MAX_LENGTH=254 ; PREFIX="Error starting GDM with your graphics card: " ; SUFFIX=". Please take note of this error and visit https://tails.boum.org/gdm for troubleshooting." ; MAX_VIDEO_CARD_LENGTH=$(($MAX_LENGTH - $(echo -n "$PREFIX$SUFFIX" | wc -c))) ; VIDEO_CARD=$(lspci -d::0300 -nn | sed -E "s,.* VGA compatible controller \[0300\]: *,," | cut -c "1-$MAX_VIDEO_CARD_LENGTH") ; /bin/plymouth display-message --text="$PREFIX$VIDEO_CARD$SUFFIX" " Adding a backslash fixes that and the command still works.
* | | Fix tails-remove-overlayfs-dirs.service (refs: #15146)segfault2019-11-241-1/+2
| | | | | | | | | | | | The service is not stopped without Conflicts=shutdown.target.
* | | Fix DefaultDependencies=no missing in tails-remove-overlayfs-dirs.service ↵segfault2019-11-241-0/+1
| | | | | | | | | | | | (refs: #15146)
* | | On shutdown, empty the tmpfs read-write branch of the overlayfs mounted on / ↵segfault2019-11-242-0/+19
| |/ |/| | | | | (refs: #15146)
* | Merge branch ↵intrigeri2019-11-151-3/+1
|\ \ | | | | | | | | | 'bugfix/17143-17214-12023-remove-obsolete-tor-browser-customization+force-all-tests' into stable (Fix-committed: #17143, #17214, #12023)
| * | htpdate: stop sending User-Agent that fakes Tor Browser (refs: #12023)intrigeri2019-11-101-3/+1
| |/ | | | | | | | | As decided on the "[Tails-dev] Faking htpdate user agent worth it?" thread in December 2016.
* | Wait until Tor has bootstrapped before we try to upgrade Additional Software ↵intrigeri2019-11-102-2/+2
|/ | | | | | | (refs: #17203) This was the intention of this code since the beginning, but unfortunately we got the unit name wrong, so our After= stances were ineffective.
* Merge remote-tracking branch 'origin/devel' into ↵intrigeri2019-10-051-6/+9
|\ | | | | | | feature/16664-simplify-tor-has-bootstrapped+force-all-tests
| * More refactoring (refs: #17098)segfault2019-10-041-6/+9
| |
* | Merge remote-tracking branch 'origin/devel' into ↵intrigeri2019-08-293-67/+2
|\ \ | |/ | | | | feature/16664-simplify-tor-has-bootstrapped+run-all-tests
| * Remove "XXX" in favour of #16964.intrigeri2019-08-101-3/+1
| |
| * Adjust boot-time backports APT pinning for Buster.intrigeri2019-08-101-1/+1
| | | | | | | | I've filed #16967 so we don't forget this again while porting to Bullseye.
| * Remove pre-generated Pidgin accounts (refs: #16744)segfault2019-07-141-63/+0
| |
* | Fix systemd unit descriptionsegfault2019-07-251-1/+1
| |
* | Use BindsTo= and After= in tor-has-bootstrapped systemd units (refs: #16664)segfault2019-07-202-9/+8
|/ | | | | | | | | | | | | | | | | | | Currently, if tor@default.service stops for some reason (either stopped manually or unexpectedly), tails-tor-has-boostrapped.target is still active. Using BindsTo= in conjunction with After= ensures that the unit is always stopped if the other unit (tor@default.service) is stopped. See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#BindsTo= This allows us to simplify config/chroot_local-includes/usr/local/sbin/tor-has-bootstrapped, which would only have to check if tails-tor-has-bootstrapped.target is active. Or, we could get rid of this script altogether, because instead of calling the script, applications can just run /bin/systemctl --quiet is-active tails-tor-has-bootstrapped.target themselves.
* Move hooks to drop-in config file snippetssegfault2019-04-041-0/+2
|
* Disable emergency shutdown during suspend (refs: #11729)segfault2019-04-041-0/+11
|
* ASP: ignore install exit codeAlan2019-03-161-1/+1
| | | | | | We want to run the upgrade even if the install step fails, so let's ignore its exit code. Will-fix: #15957
* Mount a dedicated tmpfs on /run/initramfs instead of trying to remount /run ↵intrigeri2019-01-122-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | with the "exec" option (refs: #16097). My previous approach, i.e. "let's remount /run with the exec option via a unit file started as part of the shutdown procedure", worked just fine for clean shutdown. But it does not work for emergency shutdown, i.e. when the boot medium is physically removed: for some reason (possibly missing bits in the memlockd configuration), this service is not started, and then systemd-shutdown won't return to the initramfs because /run/initramfs/shutdown is not executable. So let's instead disregard /run and extract the initramfs into a dedicated tmpfs, that we mount on /run/initramfs (where systemd-shutdown will look for it), and that we mount without the "noexec" option. Also, remove manual calls to eject(1): - They increase chances that the shutdown process breaks due to missing files locked in memory by memlockd. - Their sole benefit is to ensure we physically eject the DVD. It's unclear if this code is still needed nowadays. Regardless, starting with Tails 3.12, the only supported use case for ISO and DVD is virtual machines, which are not targeted by the emergency shutdown feature, which is about removing the *physical* boot medium.
* Fix memory erasure on shutdown with systemd v239 (refs: #16097).intrigeri2019-01-102-3/+17
| | | | | | | | | | | | | | | | | | | | | | Remounting /run with the "exec" option in /lib/systemd/system-shutdown/tails does not work anymore with systemd v239, while it worked at least until systemd v237. I could not find out why by reading systemd's NEWS file. So let's instead do this there: - For clean shutdown: in a new, dedicated service, started immediately before final.target, which itself is a synchronization point that ensures this service is started before the transition to systemd-shutdown and in turn to the initramfs, where we finish the unmounting and other clean ups needed to erase the memory. - For emergency shutdown: in the udev watchdog script, before calling the unclean shutdown code, which bypasses final.target and thus won't run tails-remount-run-exec.service. Too bad we have to duplicate this mount command but it seems that both instances will become unnecessary quickly enough, once systemd DTRT™. Another way would be to manually start tails-remount-run-exec.service from the udev watchdog script but I'm concerned it will be unreliable when the boot medium has been unplugged.
* Merge branch 'feature/15915-remove-readahead' into devel (Fix-committed: #15915)intrigeri2019-01-063-55/+1
|\
| * Start the udev watchdog for emergency shutdown only after we're ready to ↵intrigeri2018-11-191-1/+1
| | | | | | | | | | | | | | | | return to initramfs. Without this explicit ordering, we have no guarantee that /run/initramfs has been populated when udev-watchdog-wrapper is triggered and calls "systemctl --force poweroff" to return to the initramfs.
| * Remove the boot readahead feature (refs: #15915).intrigeri2018-11-182-54/+0
| | | | | | | | | | | | | | | | | | | | | | Our work on the USB image project (#15292) will deprecate booting from DVD except for VMs. So the use cases we'll still support are: - booting from a USB stick - booting a VM from an ISO In both cases, readahead does not matter much (or at all), so let's simplify things.
* | Rename pools to avoid confusion (refs: #15428)intrigeri2018-11-171-7/+7
|/ | | | | | | | People get confused by the use of pal/neutral/foe: they think we need to particularly trust members of the "pal" pool, which is incorrect and can lead to useless controversy. So let's fix this by renaming the pools and clarifying our design doc.
* Fix another regex (refs: #15973)segfault2018-09-301-1/+1
|
* Fix regex (refs #15973)segfault2018-09-291-1/+1
|
* Fix APT pinning for stretch-backportssegfault2018-09-231-3/+13
| | | | | | | | In our own repo, we use "o=Debian", but the official Debian repo uses "o=Debian Backports" for backports. Since we change the repo from ours to Debian, we also have to change the origin. In passing, add a log message and simplify another regex.
* Simplify regex (refs: #15837)segfault2018-09-201-3/+2
|
* Reconfigure custom APT repo in APT preferences (refs: #15837)segfault2018-09-191-0/+14
| | | | | | | We change our repository from deb.tails.boum.org to jenw7xbd6tf7vfhp.onion in the APT sources, so we also have to change it in the APT preferences, or else the pinning is ignored and packages from Debian repos are installed with higher priority.
* Merge remote-tracking branch 'origin/devel' into feature/14594-asp-guiintrigeri2018-08-153-3/+3
|\
| * Rename /usr/share/amnesia to /usr/share/tails.intrigeri2018-08-143-3/+3
| | | | | | | | The project was renamed, what, 8 years ago?
* | Ensure the amnesia user can cross the /media/tails-persistence-setup/ ↵intrigeri2018-06-061-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | directory boundary (refs: #15566) … by creating that directory via a live-config hook, with appropriate ownership and permissions. A newly created persistent volume is mounted on /media/tails-persistence-setup/TailsData by t-p-s (via udisks2). At the end of the (new) persistent volume configuration process, we display a "gear" icon that when clicked, starts tails-additional-software-config as the amnesia user. tails-additional-software-config needs to read /media/tails-persistence-setup/TailsData/live-additional-software.conf (otherwise tails-additional-software-config pretends no ASP is configured yet). Without these custom, relaxed permissions, that would be impossible: by default, /media/tails-persistence-setup is created (presumably by udisks2) with permissions 0700 and owned by tails-persistence-setup:root. This change is safe because: 1. /media/tails-persistence-setup/TailsData is the only thing that ever gets created under /media/tails-persistence-setup; 2. TailsData, i.e. the root of the persistent filesystem, is world-readable so under normal circumstances, when Tails was started with the persistent volume unlocked, the amnesia user would be allowed to access it anyway. Still, this change does not seem to be enough to fix the UX problem we're after here. For some reason tails-additional-software-config still pretends that no ASP is configured yet, even though it does seem to have all the permissions it needs to list them: see https://labs.riseup.net/code/issues/15566#note-7 for details.
* | ASP: use && instead of ; between the two cp commandsAlan2018-04-151-1/+1
| | | | | | | | Refs: #15431