I have a docker container, when disable selinux, it works well;
but when enabled selinux (i.e. the docker daemon is started with --selinux-enabled), it can not start up.
So the failure should caused by selinux denial, but this is not shown in the selinux audit log. when I use the "ausearch -m XXX | audit2allow ..." to generate the policy, it does not include any denial info.
want to know how to get the selinux denial info occured inside the container, so that I can use it in generating my policy file?
ps: I checked the label info of the accessed file, they seem right,but access(ls) is denied:
# ls -dlZ /usr/bin
dr-xr-xr-x. root root system_u:object_r:container_file_t:s0:c380,c857 /usr/bin
# ls /usr/bin
ls: cannot open directory /usr/bin: Permission denied
more: the selected answer answered the question, but now the problem is the audit log shows the access is to read "unlabeled_t", but as the "ls -dZ /usr/bin" shows, it is a "container_file_t". I put this in a separate question:
Why SELinux denies access to container internal files and claims them as "unlabled_t"?
The policy likely contains dontaudit rules. Dontaudit rules do not allow acecss, but suppress logging for the specific access.
You can disable dontaudit rules with semanage:
semanage dontaudit off
After solving the issue, you probably want to turn the dontaudit rules back on to reduce log noise.
It is also possible to search for possible dontaudit rules with sesearch:
sesearch --dontaudit -t container_file_t
Related
I'm trying to setup a singularity container for an image processing application, and I need it to be able to save images to a specified directory. I had originally tried using a straight -B flag, but that seems to mount a directory as read only if the container wasn't being run as root. Is there a way to either make a bind r/w for any user, or would I need to use some sort of scratch directory or fusemount?
The write permissions for the bound directory match those on the host system. If you want anyone to be able to write to a given directory, set permissions on the host with chmod 777 dir_name. Keep in mind this will allow anyone to read, write and delete files in the directory. Consider adding users to a shared group and using group permissions (chmod g+rwX dir_name) if there are people using the server who should not have access.
If the directory has the right permissions but you still can't write to it when it's bound, you may want to use singularity --debug exec ... to see that everything is being correctly bound to the container.
I have a VPN client in my Docker container (ubuntu:18.04).
The client must do the following:
mv /etc/resolv.conf /etc/resolv.conf.orig
Then the client should create new /etc/resolv.conf with their DNS servers. However, the move fails with an error:
mv: cannot move '/etc/resolv.conf' to '/etc/resolv.conf.orig': Device or resource busy
Can this be fixed? Thank you advance.
P.S.: I can 't change the VPN client code.
Within the Docker container the /etc/resolv.conf file is not an ordinary regular file. Docker manages it in a special manner: the container engine writes container-specific configuration into the file outside of the container and bind-mounts it to /etc/resolv.conf inside the container.
When your VPN client runs mv /etc/resolv.conf /etc/resolv.conf.orig, things boil down to the rename(2) syscall (or similar call from this family), and, according to the manpage for this syscall, EBUSY (Device or resource busy) error could be returned by few reasons, including the situation when the original file is a mountpoint:
EBUSY
The rename fails because oldpath or newpath is a directory that is in use by some process (perhaps as current working directory, or as root directory, or
because it was open for reading) or is in use by the system (for example as mount point), while the system considers this an error. (Note that there is no
requirement to return EBUSY in such cases — there is nothing wrong with doing the rename anyway — but it is allowed to return EBUSY if the system cannot otherwise handle such situations.)
Though there is a remark that the error is not guaranteed to be produced in such circumstances, it seems that it always fires for bind-mount targets (I guess that probably this happens here):
$ touch sourcefile destfile
$ sudo mount --bind sourcefile destfile
$ mv destfile anotherfile
mv: cannot move 'destfile' to 'anotherfile': Device or resource busy
So, similarly, you cannot move /etc/resolv.conf inside the container, for it is a bind-mount, and there is no straight solution.
Given that the bind-mount of /etc/resolv.conf is a read-write mount, not a read-only one, it is still possible to overwrite this file:
$ mount | grep resolv.conf
/dev/sda1 on /etc/resolv.conf type ext4 (rw,relatime)
So, the possible fix could be to try copying this file to the .orig backup and then rewriting the original one instead of renaming the original file and then re-creating it.
Unfortunately, this does not meet your restrictions (I can 't change the VPN client code.), so I bet that you are out of luck here.
Any method that requires moving a file onto /etc/resolv.conf fails in docker container.
The workaround is to rewrite the original file instead of moving or renaming a modified version onto it.
For example, use the following at a bash prompt:
(rc=$(sed 's/^\(nameserver 192\.168\.\)/# \1/' /etc/resolv.conf)
echo "$rc" > /etc/resolv.conf)
This works by rewriting /etc/resolv.conf as follows:
read and modify the current contents of /etc/resov.conf through the stream editor, sed
the sed script in this example is for commenting out lines starting with nameserver 192.168.
save the updated contents in a variable, rc
overwrite the original file /etc/resolv.conf with updated contents in "$rc"
The command list is in parentheses to operate in a sub-shell to avoid polluting the current shell's name space with a variable name rc, just in case it happens to be in use.
Note that this command does not require sudo since it is taking advantage of the super user privileges available by default inside the container.
Note that sed -i (editing in-place) involves moving the updated file onto the original and will not work.
But if the visual editor, vi, is available in the container, editing and saving /etc/resolv.conf with vi works, since vi modifies the original file directly.
I'm trying to use rsyslog imfile to send logs contained in Jenkins log files to a Graylog server, I added root user to jenkins group but I've still permissions issues when rsyslog tries to read files.
Here is the rsyslog script :
module(load="imfile")
ruleset(name="infiles") {
action(type="omfwd"
target="graylog.server"
protocol="tcp" port="1514" )
}
input(type="imfile" tag="jenkinsJobs"
file="/var/lib/jenkins/jobs/*/builds/*/log")
And I get the following error :
imfile: poll_tree cannot stat file '/var/lib/jenkins/jobs/test/builds/legacyIds' - ignored: Permission denied [v8.1901.0]
I also tried to let user jenkins execute the script but he can't send back logs to rsyslog, since he hasn't the permissions.
Check for selinux context using ls -lZ on target file. You can disable selinux if not required.
I am running Docker Toolbox v. 1.13.1a on Windows 7 Pro Service pack 1 x64OS.
with Virtual Box Version 5.1.14 r112924
when I try to run any docker image e.g. official postgres image from Docker Hub with volumes disabled, it works fine!
But when I enable the volumes it fails.
I tried all official documentations
The VM has shared folder as required and has full access to it also
shared folder screenshot
In case of my example of postgresql it crashes with following log
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... LOG: could not link file "pg_xlog/xlogtemp.27" to "pg_xlog/000000010000000000000001": Operation not permitted
FATAL: could not open file "pg_xlog/000000010000000000000001": No such file or directory
child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/postgresql/data"
I know its the problem with folder permissions. But kinda stuck!
A ton of thanks in advance
I've been busy with this problem all day and my conclusion that it's currently simply not possible to run postgresql inside a docker container while keeping your data persistent in a separate volume.
I even tried running the container without linking to a volume and copying the data that was originally in /var/lib/postgresql into a folder of my host OS (Windows 10 Home), then copy that into the folder that got then linked to the container itself.
Alas, I got the next error:
FATAL: data directory "/var/lib/postgresql/data/pgadmin" has wrong ownership
HINT: The server must be started by the user that owns the data directory.
In conclusion: There's something going wrong with the ownership and the correct user owning it and to be able to fix it, you'll need a unix commandline on Windows that is able to run docker (something currently not possible with Bash on Ubuntu on Windows that is running using Ubuntu 16.04 binaries).
Maybe, in the future, you'll be able to run the needed commands (found here, under Arbitrary --user Notes), but these are *nix commands and powershell (started by Kitematic) can't run those. Bash for Ubuntu for Windows could run those, but that shell has no connection to the docker daemon/service on windows...
TL;DR: Lost a day of work: It is currently impossible on Windows.
I have been trying to fix this issue also ..
At first I thought it was a symlink problem (because the first error fails on " could not link .. operation not permitted)
To be sure symlink is permitted you have to :
share a folder in virtualbox
run virtualbox as administrator (if you account is in administrator group) Right click virtualbox.exe and select run as Administrator
if your account is not administrator, add the symlink privilege with secpol.msc > "Local Policies-User Rights Assignments" add your user to "Create symbolic links"
enable symlink for your shared folder in virtualbox :
VBoxManage setextradata VM_NAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/SHARED_FOLDER_NAME 1
Alternatively you can also use the c:\User\username folder which is shared and symlink enabled by default dockertools installation
Now I can create symlinks in the shared folder from the docker container .. but I still have the same error "could not link ... operation not permitted"
So the reason must be somewhere else ... in the file permissions as you said but I do not see why ?
i would like to achieve an architecture like shown on the left side of this picture(because i want to use NXLog): http://docs.graylog.org/en/2.1/_images/sidecar_overview.png.
I have already installed Graylog2 on my RedHat Server and now i'm currently working on the configuration of collector-sidecar. As i'm working as nonroot, i had to change several directories in configuration files of collector-sidecar and NXLog. Now to the problem: Everytime i try to start collector sidecar, i get INFO/Error- Messages:
[gunge#bsul0959 bin]$ ./graylog-collector-sidecar -c /opt/ansible/sidecar/etc/graylog/collector-sidecar/collector_sidecar.yml
INFO[0000] Using collector-id: 13a3d80f-cb69-4391-8520-7a760b9b964e
INFO[0000] Fetching configurations tagged by: [linux apache syslog]
ERRO[0000] stat /var/run/graylog/collector-sidecar: no such file or directory
INFO[0000] Trying to create directory for: /var/run/graylog/collector-sidecar/nxlog.run
ERRO[0000] Not able to create directory path: /var/run/graylog/collector-sidecar
INFO[0000] Starting collector supervisor
ERRO[0010] [UpdateRegistration] Sending collector status failed. Disabling `send_status` as fallback! PUT http://127.0.0.1:12900/plugins/org.graylog.plugins.collector/collectors/13a3d80f-cb69-4391-8520-7a760b9b964e: 400 Unable to map property tags.
Known properties include: operating_system
After this start procedure, a collector appears on my Graylog Web-Interface, but if i abort the start procedure, the collector disappears again.
During the start procedure, it tries to create a path in /var/run/graylog/collector-sidecar but as i am not root, it can't. As a consequence, he can't create nxlog.run in that directory. I already tried to change the path to a place where i don't need root permissions, but i think there is no configuration file where i can do this. So i looked into the binary of collector-sidecar and found this:
func (nxc *NxConfig) ValidatePreconditions() bool {
if runtime.GOOS == "linux" {
if !common.IsDir("/var/run/graylog/collector-sidecar") {
err := common.CreatePathToFile("/var/run/graylog/collector-sidecar/nxlog.run")
if err != nil {
return false
}
}
}
return true
}
It seems, that the path is coded into the application and there is no way to configure anoter path.
Do you see a solution besides getting root permissions?
By default sidecar uses root account. Creating a new user as "collector" and giving him the files he needs and switching to his user will solve the issue.
Create the user and grant the ownership/permissions:
# useradd -r collector
# chown -R collector /etc/graylog
# chown -R collector /var/cache/graylog
# chown -R collector /var/log/graylog
# setfacl -m u:collector:r /var/log/*
Tell systemd about the new user:
# vim /etc/systemd/system/collector-sidecar.service
[Service]
User=collector
Group=collector
# systemctl daemon-reload
# systemctl restart collector-sidecar
From now on backends ( NXLog or Beats ) will use the user collector. Hope that it works for you!
Currently this is a fixed path as you saw in the code. To run it as a normal user you also have to do some more changes in the default NXlog configuration file. At the moment I would recomment you to write your own NXlog file and use it without the Sidecar in between. But you can create a GH issue so that we can add the needed option.
Cheers,
Marius