-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When granting write access to files, lock (k) permission should also be granted #92
Comments
cc @olivercalder I wasn't sure if this should be filed against |
This is one for snapd I suspect: the client is only able to respond to snapd in terms of rwx permissions which then get mapped to the reply to the kernel. |
At the moment, we're abstracting away the distinction between AppArmor Here are where the mappings from AppArmor permission to "abstract" permission are defined: In particular: "home": {
"read": notify.AA_MAY_READ | notify.AA_MAY_GETATTR,
"write": notify.AA_MAY_WRITE | notify.AA_MAY_APPEND | notify.AA_MAY_CREATE | notify.AA_MAY_DELETE | notify.AA_MAY_RENAME | notify.AA_MAY_SETATTR | notify.AA_MAY_CHMOD | notify.AA_MAY_LOCK | notify.AA_MAY_LINK,
"execute": notify.AA_MAY_EXEC | notify.AA_EXEC_MMAP,
},
If you're hitting a problem with multiple prompts appearing when trying to (presumably) open and then lock the file, if you're not replying with a rule-creating reply (e.g. "Allow always") then the problem is likely just that the application is using two distinct syscalls, and the reply to the first doesn't affect the second. An |
So something is still not working right - even after rebooting I can still reproduce this - I have granted what appears to be appropriate rules for read+write to the affected paths yet audacity still getting denied to lock the file:
|
Could you please try to collect some journalctl logs with I'm curious if this might be related to the kernel bug for which JJ worked on a fix. In that case, there was an allow rule by snapd, but still an audit deny from the kernel. Seems like a similar problem here, if we see snapd sending back an explicit allow for the lock permission. If we don't see snapd sending back an allow, the logs should shed some light on what snapd is doing wrong. |
Let me know if you more logs than the following:
|
It is quite common for applications to want to lock a file when writing to it -
k
permission should be granted in addition tow
for write access otherwise errors like the following are seen when using audacity to try and save/open a file:This path can be decoded using
aa-decode
:And we can see this matches a rule already granted as write access in the security center
The text was updated successfully, but these errors were encountered: