sudo policy plugin fails to initialize session in a Docker container: why?

Hi,

In the official openSUSE Tumbleweed docker container (i.e., that provided by running

docker pull opensuse:tumbleweed

) I installed sudo, added my user (fusion809) to the wheel group, edited my /etc/sudoers file, uncommenting %wheel lines. Then I ran sudo zypper up and it returned:


sudo: policy plugin failed session initialization

I don’t know how to fix this error. I have tried installing several patterns (including devel_basis, base, enhanced_basis, console, etc.). I have started an issue (https://github.com/openSUSE/docker-containers-build/issues/10) at the openSUSE/docker-containers-build GitHub repo, but I thought I would ask this question here in case it’s not just a bug with the Docker container and is related to the openSUSE Tumbleweed OS in it. Plus, what can I say I am desperate for an answer as it is preventing me from building packages in this container.

Thanks for your time,
Brenton

If it helps running

su

and entering my password from this user session returns:


su: cannot open session: Permission denied

Can you please copy/paste the whole in one. And not:
when I enter: …
then I get: …
But complete, prompt, input, output, next prompt. E.g.

henk@boven:~> su -
Wachtwoord:
boven:~ #

That wiill make your information look far more trustworthy.

OK, here is exactly what I think you want:


**[10:14:03] ****fusion809 ****~ $ **su
Password:  
su: cannot open session: Permission denied
**[10:14:07] ****fusion809 ****~ $ **sudo zypper up
sudo: policy plugin failed session initialization

Do you have a solution for this problem? Further prompts where I try to build packages include:


**[10:15:58]****fusion809 ****~/OBS/home:fusion809:arch_extra:extra/ffmpeg $**osc build Arch_Extra x86_64                                                         
Run source service: /usr/lib/obs/service/download_files --outdir /tmp/tmpZoxVdw
Building PKGBUILD for Arch_Extra/x86_64
Getting buildinfo from server and store to /home/fusion809/OBS/home:fusion809:arch_extra:extra/ffmpeg/.osc/_buildinfo-Arch_Extra-x86_64.xml
Getting buildconfig from server and store to /home/fusion809/OBS/home:fusion809:arch_extra:extra/ffmpeg/.osc/_buildconfig-Arch_Extra-x86_64
Updating cache of required packages
0.0% cache miss. 188/188 dependencies cached.

WARNING: unknown packages get not verified, they can compromise your system !
Writing build configuration
Running build
sudo: policy plugin failed session initialization

The buildroot was: /var/tmp/build-root/Arch_Extra-x86_64

Is there any info I’m missing? Not trying to be rude or offend ya, just I want a solution as this problem is very irritating.

This is better. But can you please copy/paste in some way without the colouring. Parts of what you post are barely readable.

It seems that su does not function properly. I have no idea about the rest of the problem you talk about, but when you want to run something as another user (root in this case) proper functioning su (and sudo) are crucial. Thus maybe we concentrate on that.

Please post

ls -l $(which su) $(which sudo)

[10:26:33] fusion809 ~/OBS/home:fusion809:arch_extra:extra/ffmpeg $ ls -l $(which su) $(which sudo)
-rwsr-xr-x 1 root root  30856 Mar 20 10:56 /usr/bin/su
-rwsr-xr-x 1 root root 138744 Mar 26 14:43 /usr/bin/sudo

the colours were because I’m using Zsh as my shell. Although these errors occur even when I’m using Bash.

I wanted to check the ownership and permission bits (specialy the SUID bit), but it all looks correct.

Hm. for the moment I am out of ideas.:frowning:

Well if it helps, it seems like this error occurs with this image out-of-the-box. I tried creating a new opensuse:tumbleweed container and setting it up for the building with the OBS and I am getting the same sudo error. Maybe if you create a docker container for opensuse:tumbleweed and install sudo you’ll get the same errors. These sudo errors do not appear to occur when running at root. I know that sudo gives root privileges so there’s no point running it as root but I did and it gave no errors. Running

su - fusion809

(where fusion809 is my user account) gives no errors either and runs fine. It’s only the child processes of su - fusion809 that give these errors when sudo/su is run.

On Thu 31 Mar 2016 11:26:01 AM CDT, fusion809 wrote:

Well if it helps, it seems like this error occurs with this image
out-of-the-box. I tried creating a new opensuse:tumbleweed container and
setting it up for the building with the OBS and I am getting the same
sudo error. Maybe if you create a docker container for
opensuse:tumbleweed and install sudo you’ll get the same errors. These
sudo errors do not appear to occur when running at root. I know that
sudo gives root privileges so there’s no point running it as root but I
did and it gave no errors. Running
Code:

su - fusion809

(where fusion809 is my user account) gives no errors either and runs
fine. It’s only the child processes of su - fusion809 that give these
errors when sudo/su is run.

Hi
To run docker as my user, all I did was run visudo and add;


<username> ALL = NOPASSWD: /usr/bin/docker

No manual editing of /etc/sudoers, no %wheel…


Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 SP1|GNOME 3.10.4|3.12.53-60.30-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

I’ve been Googling this problem several times before and after asking this question. Many answers have pertained to Arch Linux containers wherein the answer involves the /etc/security/limits.conf file. This file for me atm is:


# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain>        <type>  <item>  <value>
#
#Where:
#<domain> can be:
#        - a user name
#        - a group name, with @group syntax
#        - the wildcard *, for default entry
#        - the wildcard %, can be also used with %group syntax,
#                 for maxlogin limit
#
#<type> can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits
#
#<item> can be one of the following:
#        - core - limits the core file size (KB)
#        - data - max data size (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - max locked-in-memory address space (KB)
#        - nofile - max number of open file descriptors
#        - rss - max resident set size (KB)
#        - stack - max stack size (KB)
#        - cpu - max CPU time (MIN)
#        - nproc - max number of processes
#        - as - address space limit (KB)
#        - maxlogins - max number of logins for this user
#        - maxsyslogins - max number of logins on the system
#        - priority - the priority to run user process with
#        - locks - max number of file locks the user can hold
#        - sigpending - max number of pending signals
#        - msgqueue - max memory used by POSIX message queues (bytes)
#        - nice - max nice priority allowed to raise to values: -20, 19]
#        - rtprio - max realtime priority
#
#<domain>      <type>  <item>         <value>
#


#*               soft    core            0
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4


# harden against fork-bombs
*               hard    nproc           1700
*               soft    nproc           1200
root            hard    nproc           3000
root            soft    nproc           1850
# End of file

the solution I have read has been changing the line:


*         -        nice         0

to:


#*         -        nice         0

as you can see, however, I don’t have this line in my file at all.

@malcomlewis - sorry, you seem to have misunderstood what this question is about. I can run docker without a problem (i.e., running docker run -i -t CONTAINER /bin/zsh happens without a hitch, my user account is added to the docker group so there’s no problem there), it is running sudo from WITHIN a docker container that is the problem.

ps. malcolm I mentioned you in another post (not sure how to CC someone in a forum post though) https://forums.opensuse.org/showthread.php/516872-Is-it-possible-to-build-a-ffmpeg-package-without-it-containing-proprietary-software.

On Thu 31 Mar 2016 11:56:05 AM CDT, fusion809 wrote:

@malcomlewis — sorry, you seem to have misunderstood what this
question is about. I can run docker without a problem (i.e., running
docker run -i -t CONTAINER /bin/zsh happens without a hitch, my user
account is added to the docker group so there’s no problem there), it is
running sudo from WITHIN a docker container that is the problem.

ps. malcolm I mentioned you in another post (not sure how to CC someone
in a forum post though) Is it possible to build a ffmpeg package, without it containing proprietary software? - Open Build Service (OBS) - openSUSE Forums.

Hi
Ahh OK, understand now :wink:

Hmmm, I just cleaned things out and did a docker pull
opensuse:tumbleweed, fired it up and did a cat /etc/os-release and it
shows it’s Leap…?


Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 SP1|GNOME 3.10.4|3.12.53-60.30-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

For me it doesn’t. Maybe cause I’m running Docker on Arch Linux and not openSUSE Leap like you are?


[13:38:37]  security # cat /etc/os-release
NAME=openSUSE
VERSION="Tumbleweed"
VERSION_ID="20160329"
PRETTY_NAME="openSUSE Tumbleweed (20160329) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:20160329"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
ID_LIKE="suse"

Your comment, Malcolm, caused me to check if this sudo error existed in a Leap container and it doesn’t. In the Leap container sudo and su are running fine. So it does seem to be Tumbleweed-specific.