github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #4480] can't lock mbox file with evolution #2680

New issue

Closed

opened 2026-05-05 09:20:32 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 09:20:32 -06:00

Owner

Originally created by @loveshack on GitHub (Aug 25, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4480

This is with firejail 0.9.66 on Debian 11 with apparmor.

evolution fails to read my mbox in /var/mail, saying it can't lock the file.
I followed the instructions in thunderbird.profile, so edited the apparmor file to contain

owner /var/{mail,spool/mail}/** w,

reloaded apparmor, and added the suggested snippet to evolution.local:

noblacklist /var/mail
noblacklist /var/spool/mail
whitelist /var/mail
whitelist /var/spool/mail
writable-var

without luck.

Debugging suggestions welcome, of course, if I haven't missed something obvious.

Originally created by @loveshack on GitHub (Aug 25, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4480 This is with firejail 0.9.66 on Debian 11 with apparmor. evolution fails to read my mbox in /var/mail, saying it can't lock the file. I followed the instructions in thunderbird.profile, so edited the apparmor file to contain ``` owner /var/{mail,spool/mail}/** w, ``` reloaded apparmor, and added the suggested snippet to evolution.local: ``` noblacklist /var/mail noblacklist /var/spool/mail whitelist /var/mail whitelist /var/spool/mail writable-var ``` without luck. Debugging suggestions welcome, of course, if I haven't missed something obvious.

gitea-mirror

2026-05-05 09:20:32 -06:00

closed this issue
added the
stale
label

gitea-mirror commented

2026-05-05 09:20:35 -06:00

Author

Owner

@reinerh commented on GitHub (Aug 26, 2021):

owner /var/{mail,spool/mail}/** w,

In AppArmor you can allow locking files with mode k. Does this work by chance?

@reinerh commented on GitHub (Aug 26, 2021): > owner /var/{mail,spool/mail}/** w, In AppArmor you can allow locking files with mode `k`. Does this work by chance?

gitea-mirror commented

2026-05-05 09:20:36 -06:00

Author

Owner

@loveshack commented on GitHub (Aug 26, 2021):

owner /var/{mail,spool/mail}/** w,

In AppArmor you can allow locking files with mode k. Does this work by chance?

Thanks, but it doesn't help to use "wk" instead of "w" there.

I wonder if it's related to how locking is actually done. Debian has an
sgid helper "mail-lock" for locking the mail spool generally, and
evolution has an sgid /usr/libexec/camel-lock-helper-1.2 which I assume
does the same thing. Other than what mail-lock does, I don't know how
any of this works, unfortunately, but I can try any other ideas, or try
to debug with any hints there are, probably next week. I would feel
happier running evolution sandboxed when I need it.

@loveshack commented on GitHub (Aug 26, 2021): >> owner /var/{mail,spool/mail}/** w, > > In AppArmor you can allow locking files with mode `k`. Does this work by chance? Thanks, but it doesn't help to use "wk" instead of "w" there. I wonder if it's related to how locking is actually done. Debian has an sgid helper "mail-lock" for locking the mail spool generally, and evolution has an sgid /usr/libexec/camel-lock-helper-1.2 which I assume does the same thing. Other than what mail-lock does, I don't know how any of this works, unfortunately, but I can try any other ideas, or try to debug with any hints there are, probably next week. I would feel happier running evolution sandboxed when I need it.

gitea-mirror commented

2026-05-05 09:20:37 -06:00

Author

Owner

@reinerh commented on GitHub (Aug 26, 2021):

When it relies on sgid helpers, it might be related to this:

       nonewprivs
              Sets the NO_NEW_PRIVS prctl.  This ensures that child processes cannot acquire new privileges using execve(2);  in particular, this means that calling a suid binary (or one with file capabilities) does not result in  an
              increase of privilege.

(this is set in firefox-common.profile, included in thunderbird.profile)

@reinerh commented on GitHub (Aug 26, 2021): When it relies on sgid helpers, it might be related to this: ``` nonewprivs Sets the NO_NEW_PRIVS prctl. This ensures that child processes cannot acquire new privileges using execve(2); in particular, this means that calling a suid binary (or one with file capabilities) does not result in an increase of privilege. ``` (this is set in firefox-common.profile, included in thunderbird.profile)

gitea-mirror commented

2026-05-05 09:20:37 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 27, 2021):

seccomp (seccomp*, protocol, memory-deny-write-execute) implies NNP.
noroot/nogroups may also interfere sgid helpers.

@rusty-snake commented on GitHub (Aug 27, 2021): seccomp (`seccomp*`, `protocol`, `memory-deny-write-execute`) implies NNP. `noroot`/`nogroups` may also interfere sgid helpers.

gitea-mirror commented

2026-05-05 09:20:38 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 9, 2021):

I'm closing here due to inactivity, please fell free to request to reopen if you still have this issue.

@rusty-snake commented on GitHub (Oct 9, 2021): I'm closing here due to inactivity, please fell free to request to reopen if you still have this issue.

gitea-mirror referenced this issue

2026-05-05 10:20:54 -06:00

[PR #2680] [MERGED] Mumble: add new path for client data #4481

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2680

No description provided.

Rows
Columns