Hi guys I have _rootless_ container with PyTorch from ROCm -> $ { export _NAME="pytorch_rocm"; export _PATH=${HOME}/containers/FLATfiles/${_NAME}; echo; mkdir -p ${_PATH}/{,root,dockerx}; }; podman run -dt --device=/dev/kfd --device=/dev/dri --group-add video --shm-size 8G --security-opt seccomp=unconfined --volume ${_PATH}/root:/root:z --volume ${_PATH}/dockerx:/dockerx:z -w /dockerx --name ${_NAME/\//_} rocm/pytorch:latest which fails to: root@4bc3c2ec2ab3:/dockerx# python3 -c 'import torch; print(torch.cuda.is_available())' False Such _rootful_ container seems a okey but rootless "suffers" such failures due to SELinux denials I think: ... SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9 from 'read, write' accesses on the chr_file kfd. For complete SELinux messages run: sealert -l 6b3db344-2ffc-4ecd-aa2c-2c1a2bfe23e4 SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9 from 'read, write' accesses on the chr_file kfd. Would you know if this can be fixed, possibly without building extra SE module(s)? many thanks, L.
Note: I'm not an expert, but I know enough to be dangerous. Dan would know for sure, but my best guess is "no", you probably need a SELinux policy module to allow this activity. The other option is to run the container unconfined, maybe the "protections" provided by being rootless are "good enough" for your use-case? In case it helps, the (maybe) good news is, (at least as of a few years ago) there were some handy tools available for generating these policies based on SELinux denials. The workflow (use to) look something like: 1. Go into permissive mode 2. Do the container thing 3. Run the script that scrapes audit.log and generates policy-module code. 4. Compile & install the new module. 5. Repeat from step 2, until the thing is working as expected. --- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer If there's a "hard-way", I'm the first one to implement it. On 2/17/24 08:31, lejeczek via Podman wrote:
Hi guys
I have _rootless_ container with PyTorch from ROCm
-> $ { export _NAME="pytorch_rocm"; export _PATH=${HOME}/containers/FLATfiles/${_NAME}; echo; mkdir -p ${_PATH}/{,root,dockerx}; }; podman run -dt --device=/dev/kfd --device=/dev/dri --group-add video --shm-size 8G --security-opt seccomp=unconfined --volume ${_PATH}/root:/root:z --volume ${_PATH}/dockerx:/dockerx:z -w /dockerx --name ${_NAME/\//_} rocm/pytorch:latest
which fails to: root@4bc3c2ec2ab3:/dockerx# python3 -c 'import torch; print(torch.cuda.is_available())' False
Such _rootful_ container seems a okey but rootless "suffers" such failures due to SELinux denials I think: ... SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9 from 'read, write' accesses on the chr_file kfd. For complete SELinux messages run: sealert -l 6b3db344-2ffc-4ecd-aa2c-2c1a2bfe23e4 SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9 from 'read, write' accesses on the chr_file kfd.
Would you know if this can be fixed, possibly without building extra SE module(s)? many thanks, L.
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 2/20/24 1:45 PM, Chris Evich wrote:
Note: I'm not an expert, but I know enough to be dangerous.
Dan would know for sure, but my best guess is "no", you probably need a SELinux policy module to allow this activity. The other option is to run the container unconfined, maybe the "protections" provided by being rootless are "good enough" for your use-case?
In case it helps, the (maybe) good news is, (at least as of a few years ago) there were some handy tools available for generating these policies based on SELinux denials. The workflow (use to) look something like:
1. Go into permissive mode 2. Do the container thing 3. Run the script that scrapes audit.log and generates policy-module code. 4. Compile & install the new module. 5. Repeat from step 2, until the thing is working as expected.
--- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer If there's a "hard-way", I'm the first one to implement it.
On 2/17/24 08:31, lejeczek via Podman wrote:
Hi guys
I have _rootless_ container with PyTorch from ROCm
-> $ { export _NAME="pytorch_rocm"; export _PATH=${HOME}/containers/FLATfiles/${_NAME}; echo; mkdir -p ${_PATH}/{,root,dockerx}; }; podman run -dt --device=/dev/kfd --device=/dev/dri --group-add video --shm-size 8G --security-opt seccomp=unconfined --volume ${_PATH}/root:/root:z --volume ${_PATH}/dockerx:/dockerx:z -w /dockerx --name ${_NAME/\//_} rocm/pytorch:latest
which fails to: root@4bc3c2ec2ab3:/dockerx# python3 -c 'import torch; print(torch.cuda.is_available())' False
Such _rootful_ container seems a okey but rootless "suffers" such failures due to SELinux denials I think: ... SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9 from 'read, write' accesses on the chr_file kfd. For complete SELinux messages run: sealert -l 6b3db344-2ffc-4ecd-aa2c-2c1a2bfe23e4 SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9 from 'read, write' accesses on the chr_file kfd.
Would you know if this can be fixed, possibly without building extra SE module(s)? many thanks, L.
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Do you have the AVC messages? sudo ausearch -m avc -ts recent
On 2/20/24 1:45 PM, Chris Evich wrote:
Note: I'm not an expert, but I know enough to be dangerous.
Dan would know for sure, but my best guess is "no", you probably need a SELinux policy module to allow this activity. The other option is to run the container unconfined, maybe the "protections" provided by being rootless are "good enough" for your use-case?
In case it helps, the (maybe) good news is, (at least as of a few years ago) there were some handy tools available for generating these policies based on SELinux denials. The workflow (use to) look something like:
1. Go into permissive mode 2. Do the container thing 3. Run the script that scrapes audit.log and generates policy-module code. 4. Compile & install the new module. 5. Repeat from step 2, until the thing is working as expected.
--- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer If there's a "hard-way", I'm the first one to implement it.
On 2/17/24 08:31, lejeczek via Podman wrote:
Hi guys
I have _rootless_ container with PyTorch from ROCm
-> $ { export _NAME="pytorch_rocm"; export _PATH=${HOME}/containers/FLATfiles/${_NAME}; echo; mkdir -p ${_PATH}/{,root,dockerx}; }; podman run -dt --device=/dev/kfd --device=/dev/dri --group-add video --shm-size 8G --security-opt seccomp=unconfined --volume ${_PATH}/root:/root:z --volume ${_PATH}/dockerx:/dockerx:z -w /dockerx --name ${_NAME/\//_} rocm/pytorch:latest
which fails to: root@4bc3c2ec2ab3:/dockerx# python3 -c 'import torch; print(torch.cuda.is_available())' False
Such _rootful_ container seems a okey but rootless "suffers" such failures due to SELinux denials I think: ... SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9 from 'read, write' accesses on the chr_file kfd. For complete SELinux messages run: sealert -l 6b3db344-2ffc-4ecd-aa2c-2c1a2bfe23e4 SELinux is preventing /opt/conda/envs/py_3.9/bin/python3.9 from 'read, write' accesses on the chr_file kfd.
Would you know if this can be fixed, possibly without building extra SE module(s)? many thanks, L.
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
You could also enable this boolean: $ sudo setsebool -P container_use_devices true
participants (3)
-
Chris Evich -
Daniel Walsh -
lejeczek