[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

live mode /etc/apparmor.d/tunables/home.d/live-mode breaks aa-enforce

Continuing the discussion from aa-genprof is broken on Whonix.:

Doesn’t only break aa-genproof.

sudo aa-enforce /etc/apparmor.d/home.tor-browser.start-tor-browser ; echo $?
ERROR: Values added to a non-existing variable @{HOMEDIRS}: /rw/home/ in tunables/home.d/live-mode
1

This makes debugging apparmor issues (currently on Tor Browser 8.* won't launch) cumbersome. Any workaround?

//cc @Algernon

Beyond commenting the lines or removing the file, currently not.

1 Like

Why not keep it commented and only uncomment it when in live mode?

Then, users who aren’t using live mode won’t be affected by this bug.

1 Like

madaidan via Whonix Forum:

Why not keep it commented and only uncomment it when in live mode?

Then, users who aren’t using live mode won’t be affected by this bug.

Sounds great!

Also that line could be moved to a separate file to make editing through
scripts easier.

Could you implement a systemd unit file that does that please?

1 Like

What package?

1 Like

since that package ships the offending file. Seems best fit.

1 Like

I’m not sure if grepping /proc/cmdline for boot=live is the correct way to test for live mode or not but it works.

1 Like

systemd
ConditionKernelCommandLine

But grep is also good since then I can add an else to undo.

I’ll port to str_replace.

1 Like

Thanks!

Merged. And added a serious of commits on top.

https://github.com/Whonix/apparmor-profile-anondist/compare/4.7-1...4.8-1

1 Like

What are the advantages over sed?

1 Like

When updating (with the developer repository), I now get this message

Configuration file ‘/etc/apparmor.d/tunables/home.d/live-mode’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** live-mode (Y/I/N/O/D/Z) [default=N] ?

Similar to /etc/machine-id. We should probably figure out a way to skip this if possible.

1 Like

madaidan via Whonix Forum:

What are the advantages over sed?

No interpretation of special characters. Therefore and generally much
more easy to grasp syntax.

1 Like

madaidan via Whonix Forum:

When updating (with the developer repository), I now get this message

Configuration file ‘/etc/apparmor.d/tunables/home.d/live-mode’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** live-mode (Y/I/N/O/D/Z) [default=N] ?

Similar to /etc/machine-id.

Didn’t happen to me. Probably happen because you modified the file locally before the upgrade.

[1] This prompt would still happen when upgrading in live-mode since then “Modified (by you or by a script) since installation.” is true.

Should not happen in persistent-mode since then package default config gets replaced with newer package default config.

We should probably figure out a way to skip this if possible.

Would be worth figuring out anyhow generally. [1] is a good enough reason to do so.


It’s happening because the file is placed in /etc, therefore considered a configuration file.

Root causes: Debian isn’t stateless. Doesn’t have clean separation of distribution shipped files and user generated/modified files. It’s not possible to simply wipe /etc and /var to be back at the same state as everyone else using the same version. See these two blog posts for more detail to see what I mean:


Other root causes:

  • apparmor profiles aren’t in non-/etc. Apparmor profiles by packages in /usr or /lib (not sure) would not cause this issue. Then package default would be installed.
  • original apparmor bug which makes this required in first place.

There is one approach (just an approach, not a solution).

Well, there is apt-get-noninteractive. See man apt-get-noninteractive.


In other words apt can pass option(s) to dpkg to make it run non-interactively. Question can be answered beforehand.

sudo apt-get -o Dpkg::Options::=--force-confnew

This (apt-get-noninteractive) works for most packages. Well, there are some non-free firmware packages which ask special questions which are non-trivial to cover (but covered in Whonix).

Could also be set through a dpkg option but that would apply to all packages always installing package version and deactivating (move to backup file .dpkg-old (?) of locally modified configuration file version).

Something like /etc/dpkg/dpkg.cfg.d/50_user.cfg

Dpkg::Options:: --force-unsafe-io;

… might work. But not a great solution.

Other than that, I currently have no idea how to avoid this.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]