+1

FWIW Ansible 2.19+ broke sudo out of the box on Debian/Ubuntu unless sudo is configured; see https://github.com/ansible/ansible/issues/85536 - so I am glad this is a Change Proposal.

If this does affect Fedora too, It might be worth at least documenting this, or shipping a preset subpackage that drop in an override in /etc/sudoers.d/. Happy to help test if/when a COPR is available.

+1

+1 (as one of the change owners)

FWIW Ansible 2.19+ broke sudo out of the box on Debian/Ubuntu unless sudo is configured; see https://github.com/ansible/ansible/issues/85536 - so I am glad this is a Change Proposal.

If this does affect Fedora too, It might be worth at least documenting this, or shipping a preset subpackage that drop in an override in /etc/sudoers.d/. Happy to help test if/when a COPR is available.

Definitely document, not sure the implications of shipping a drop in there... would also require Requiring sudo, which may not be something some people want.

Thanks for the feedback.

FWIW Ansible 2.19+ broke sudo out of the box on Debian/Ubuntu unless sudo is configured; see https://github.com/ansible/ansible/issues/85536 - so I am glad this is a Change Proposal.

I don't think that's quite accurate. This issue only affects playbooks running against localhost with the local connection plugin. And sudo escalation in Ansible via become isn't broken. It's just no longer possible to use the sudo password cached for the current tty. This is done on purpose (

The setsid call is being done for security and consistency reasons, mostly to avoid child processes from accessing the parent TTY directly and corrupting data sent back.

), and the connection plugin was apparently never designed to be used this way in the first place. It's still possible to use --ask-become-pass or set up passwordless sudo (ideally with a dedicated user solely for ansible usage) or to run ansible itself as root.

shipping a preset subpackage that drop in an override in /etc/sudoers.d/

A policy to allow the sudo cache to persist across ttys as in https://github.com/ansible/ansible/issues/85536#issuecomment-3127724639? I don't think that's a good idea when there are other supported ways to do this that continue to be available. If users know what they're doing and really need to weaken their sudo configuration, they still can.

Definitely document

I filed https://github.com/ansible/ansible/issues/86299 to have this properly documented in the upstream porting guide that's linked in the Change. The two most major breaking changes are enumerated explicitly in the Change, but I'd prefer to defer to the upstream porting guide for everything else.

(as one of the change owners)

Side note: For some reason the Owners section of FESCo Change tickets have all been broken recently (not using the correct @ mentions and omitting people — @kevin in this case). Perhaps related to https://pagure.io/fesco/issue/3515?

Considering our audience, breaking sudo by default in Fedora is probably unacceptable. We need an easy to activate method to deal with that, or otherwise people are going be very angry about this.

Aside from that, +1 from me. I would really like a fix with this change so that Fedora family distributions aren't affected by the sudo problem.

breaking sudo by default in Fedora [...] people are going be very angry about this

I'm sorry, but I don't understand. That's not what the issue says. People using standard privilege escalation methods in Ansible are not impacted by this change, and it has no impact on any other programs or usages of sudo.

+1

Thanks for the feedback.

FWIW Ansible 2.19+ broke sudo out of the box on Debian/Ubuntu unless sudo is configured; see https://github.com/ansible/ansible/issues/85536 - so I am glad this is a Change Proposal.

I don't think that's quite accurate. This issue only affects playbooks running against localhost with the local connection plugin. And sudo escalation in Ansible via become isn't broken. It's just no longer possible to use the sudo password cached for the current tty. This is done on purpose (

Ah, you're quite right, it's only for the local connection plugin. For those of us who configure our user environments with Ansible, it's quite convenient to run it this way though (and without a dedicated user). Having experienced using Chef where it runs as root by default, configuring things for a system's main user is a pain.

The setsid call is being done for security and consistency reasons, mostly to avoid child processes from accessing the parent TTY directly and corrupting data sent back.

), and the connection plugin was apparently never designed to be used this way in the first place. It's still possible to use --ask-become-pass or set up passwordless sudo (ideally with a dedicated user solely for ansible usage) or to run ansible itself as root.

IIRC even passing --ask-become-pass / -K did not work - that could be a bug though, I can retry.

After a week, this is APPROVED (+5, 0, 0)

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GN4HRE2R7OBP73CQFBAXIDO7VGUQZE32/

@gotmax23

OK, all clear for us at least: the problem is Ansible is not behaving well with Ubuntu switching sudo to sudo-rs. Fun... just like their uutils premature switch.

With sudo-rs, without -K calls requiring become fails, with -K they still fail but fact gathering steps also fail. Reverting to normal sudo, everything works fine with -K.

so we should remember this if/when someone tries to switch us to sudo-rs ...