Ansible vs. ipa-server-install vs. RHEL8

[Dominik Vogt]

Problem
-------

A machine has just been installed with a minimal RHEL8.1 distro.
Note that in /etc/login.defs there is the line

  UMASK 0077

Installing the server from a shell works fine:

  $ umask
  0022
  $ ipa-server-install <options>
  ...
  OK

However, installing the server through Ansible (2.9.6) from
another host does *not* work.

Snippet from the Ansible script:

 ...
 - name: Install ipa-server
   shell: |
     /usr/bin/umask 022 && /usr/bin/ipa-server-install <options>
 ...

=>

The installer complains about the umask being 0077 and that it
should be 0022.  Removing the UMASK line from login.defs fixes the
immediate problem.  There is really no Ansible configuration

Questions
---------

1) Is there a good way to fix this without opening up system umask?
2) If I comment out the UMASK line from login.defs for the
   installation and reactivate it afterwards, will that cause
   problems later?

(I think this is about access rights to the certificates of the
builtin dogtag.)

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt

[Alexander Bokovoy]

On to, 31 joulu 2020, Dominik Vogt via FreeIPA-users wrote:
> Problem
> -------
>
> A machine has just been installed with a minimal RHEL8.1 distro.
> Note that in /etc/login.defs there is the line
>
>   UMASK 0077
>
> Installing the server from a shell works fine:
>
>   $ umask
>   0022
>   $ ipa-server-install <options>
>   ...
>   OK
>
> However, installing the server through Ansible (2.9.6) from
> another host does *not* work.
>
> Snippet from the Ansible script:
>
>  ...
>  - name: Install ipa-server
>    shell: |
>      /usr/bin/umask 022 && /usr/bin/ipa-server-install <options>
>  ...
>
> =>
>
> The installer complains about the umask being 0077 and that it
> should be 0022.  Removing the UMASK line from login.defs fixes the
> immediate problem.  There is really no Ansible configuration
>
> Questions
> ---------
>
> 1) Is there a good way to fix this without opening up system umask?
> 2) If I comment out the UMASK line from login.defs for the
>    installation and reactivate it afterwards, will that cause
>    problems later?
>
> (I think this is about access rights to the certificates of the
> builtin dogtag.) 
Update to RHEL 8.3. You can 'fix' ssh sessions behavior by changing how
post login it is handled by pam_umask in PAM stack for sshd. But that's
only half story.

Bug on UMASK difference for sshd-initiated sessions was raised as
https://bugzilla.redhat.com/show_bug.cgi?id=1777718. Its fix, in turn,
has caused a more severe bug in FreeIPA environments due to
a misunderstanding on how oddjob's mkhomedir PAM module works:
https://bugzilla.redhat.com/show_bug.cgi?id=1886362#c1. I had to make
that bug a blocker for RHEL 8.3.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland