On 11/5/24 4:50 PM, Stefan Berger wrote:
> > One of swtpm or apparmor must be wrong here and I think it should
be fixed. In particular, having the failure mode be "something
As stated, we were going to fix the AppArmor path in the swtpm Ubuntu
package.
But AIUI the solution you've proposed is to add the user
temp directory -- abstractions/user-tmp looks like it
adds permissions for $HOME/tmp, /var/tmp and /tmp/. None
of those will fix the failure we ran into, because we're not
using any of those tmp directories. We use a directory
that's a subdirectory of wherever the user put the build
directory, which can be anywhere the user has permissions for.
Yes, you are right. The same test failed for me locally due to the usage
of /var/tmp/ path but that's not what was originally reported.
I am not aware that user-started programs can have an exception from
having their profiles applied, nor do I know whether rules exist that
allow a user to circumvent any rule. So my guess is we need rules like
either one of the following:
owner /mnt/** rwkl
or worse:
owner /** rwkl
I don't see another choice than adding one of these rules, maybe even
the 2nd. Lena?
If there was value in the path-confinement of swtpm (for a few years) do
we really want to loose it now because of a test case? We could either
- adjust the test case to have swtpm use a directory under one of the
accepted paths, e.g., /tmp or /var/tmp
- or add /mnt as a newly supported path to the AppArmor profile
The latter works for the setup that Peter has but a new user creating
paths under /mymnt would cause the same discussion again.
Stefan
