On 1/14/26 01:19, Fei Shao wrote:
Hi all,
I write a py script to test the dac_override option, but I failed.
The py script is :
----------------------------------------------------
#!/usr/bin/env python3
import os # 用于文件/目录的基础操作（删除、判断文件是否存在）
import time
def create_file(file_path, content="默认初始内容\n"):
try:
if os.path.exists(file_path):
print(f"⚠️ 文件 {file_path} 已存在，跳过新建操作")
return False
with open(file_path, "w", encoding="utf-8") as f:
f.write(content)
print(f"successfully :{file_path}")
return True
except Exception as e:
print(f" failed : {e}")
return False
if __name__ == "__main__":
test_file = "/home/sf/apparmor/test/test_file"+str(int(time.time()))
+".txt"
create_file(test_file, "content of file \n")
----------------------------------------------------
the profile is :
--------------------------------------------------------
abi <abi/4.0>,
include <tunables/global>
profile /home/sf/apparmor/operfile.py {
include <abstractions/base>
include <abstractions/evince>
include <abstractions/python>
capability dac_override,
capability dac_read_search,
/etc/apt/apt.conf.d/ r,
/etc/apt/apt.conf.d/** r,
/home/sf/apparmor/operfile.py r,
/home/sf/apparmor/test/ rwix,
/home/sf/apparmor/test/** rw,
/proc/self/mem r, # 进程内存访问（Python 运行必需）
/sys/devices/** r, # 系统设备信息（可选，视脚本需求）
/tmp/** rw, # 临时文件目录（Python 常用）
/usr/bin/python3.12 mrix,
/var/tmp/** rw, # 系统临时目录
owner /home/*/apparmor/ r,
/usr/lib/python3*/** r, # Python 库文件读取
}
---------------------------------------------------------------
I use the command "sudo aa-enforce home.sf.apparmor.operfile.py" to make sure
the profile is loaded.
When the attribute of "/home/sf/apparmor/test/" is 755, the script worked well with
command "./operfile.py".
When the attribute of "/home/sf/apparmor/test/" is 555, command "./operfile.py" returned
"failed : [Errno 13] Permission denied: '/home/sf/apparmor/test/test_file1768381998.txt'". If I use the
"sudo ./operfile.py", the file could be created well. It seems the dac_overried doesn't work here.
who is the owner of the file in the failure case, and what is the user
id of the task trying to access the file.
As Zygmunt has already pointed out the AppArmor capability rule
doesn't elevate capabilities, it just ensures that the task can have
the given capability. AppArmor mediation works in conjunction with
regular DAC mediation, and is purely restrictive, that is to say
it will not allow something DAC doesn't allow.
While I don't have the full information about your system I am fairly
sure you are seeing DAC reject access to the file. If you look in your
system logs, you will find that there isn't an AppArmor denial message
for this event. Instead what is happening is AppArmor is allowing the
access but DAC is denying it.
I checked with "sudo aa-logprof", but no information is returned.
this indicates that there isn't a denial message from apparmor in your logs
Would you like tell me why the py script can't create file when test folder is
555 please?
so as stated above this looks to be a DAC permission issue. Though I
will add on the AppArmor side the director permissions are not what is
important (they still are important on the DAC side). Instead AppArmor
permissions have to be set for the file within the dir (which you do
have in the profile).
