RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1196451 - default requiretty is problematic and breaks valid usage
Summary: default requiretty is problematic and breaks valid usage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sudo
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Daniel Kopeček
QA Contact: Dalibor Pospíšil
URL:
Whiteboard:
: 1350922 (view as bug list)
Depends On: 1020147 1350922
Blocks: 1143927
TreeView+ depends on / blocked
 
Reported: 2015-02-26 01:17 UTC by Sage Grigull
Modified: 2016-11-03 20:31 UTC (History)
15 users (show)

Fixed In Version: sudo-1.8.6p7-18.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1020147
Environment:
Last Closed: 2016-11-03 20:31:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
proposed patch (557 bytes, patch)
2016-05-09 11:27 UTC, Daniel Kopeček
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2593 0 normal SHIPPED_LIVE Low: sudo security, bug fix, and enhancement update 2016-11-03 12:10:56 UTC

Description Sage Grigull 2015-02-26 01:17:11 UTC
+++ This bug was initially created as a clone of Bug #1020147 +++

++ sudo-1.8.6p7-11.el7.x86_64



Description of problem:

/etc/sudoers shipped with sudo modifies the default behavior to always require a controlling terminal:

...
#
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear. 
#         You have to run "ssh -t hostname sudo <cmd>".
#
Defaults    requiretty
...

However this is totally bogus because sudo will *not* ask for password if it can't set the terminal into noecho mode (unless visiblepw option is set), promptly refusing with "no tty present and no askpass program specified" message.

This breaks NOPASSWD usage, especially when sudo is run with -n switch instructing it not to ask for password at all.

Version-Release number of selected component (if applicable):
sudo-1.8.6p7-1.fc19.x86_64
but according to bug 228534 it's there since long

How reproducible:
100%

Steps to Reproduce:
1. set up NOPASSWD sudo entry
2. ssh host sudo -n command

Actual results:
execution refused with "sorry, you must have a tty to run sudo" message

Expected results:
command executed

Additional info:

--- Additional comment from Kashyap Chamarthy on 2014-02-24 07:29:04 EST ---

Ping.

I was notified that this bug is one of the blockers for having Fedora as part of upstream OpenStack CI infrastructure to run Gating tests.

Daniel, when you have some time, can you please assess the nature of the problem and post your analysis for having this fixed?

Thanks.

--- Additional comment from Vaidas Jablonskis on 2014-02-24 08:20:36 EST ---

This works though: ssh -t host 'sudo -n command'

I think `requiretty` is a sensible default and should not be turned off. It can be disabled per user or even per command if needed.

--- Additional comment from Roman Kagan on 2014-02-24 08:30:45 EST ---

(In reply to Vaidas Jablonskis from comment #2)
> This works though: ssh -t host 'sudo -n command'

Provided the caller has a tty.  Which is not the case when running this e.g. from under a daemon.

And it makes zero sense to create a pty pair only to make (RH version of) sudo happy, without the need to pass any data through it.

> I think `requiretty` is a sensible default and should not be turned off.

Mind explaining why?  It adds no security, it diverges from the upstream, it breaks valid usage.  Is there anything on the upside?

--- Additional comment from Daniel Kopeček on 2014-02-24 08:55:21 EST ---

(In reply to Roman Kagan from comment #0)
> Description of problem:
> 
> /etc/sudoers shipped with sudo modifies the default behavior to always
> require a controlling terminal:
> 
> ...
> #
> # Disable "ssh hostname sudo <cmd>", because it will show the password in
> clear. 
> #         You have to run "ssh -t hostname sudo <cmd>".
> #
> Defaults    requiretty
> ...
> 
> However this is totally bogus because sudo will *not* ask for password if it
> can't set the terminal into noecho mode (unless visiblepw option is set),
> promptly refusing with "no tty present and no askpass program specified"
> message.
> 
> This breaks NOPASSWD usage, especially when sudo is run with -n switch
> instructing it not to ask for password at all.

I agree that this might be annoying for the NOPASSWD case, but you can always use ssh -t, add custom per-command or per-user modifications (like !requiretty for a set of commands, users, etc.) to this behaviour to the sudoers.d directory. Or just simply comment out this setting if your setup needs it.

--- Additional comment from Roman Kagan on 2014-02-24 09:24:32 EST ---

Well, I know how to work around this.

But nobody has yet explained why I have to.

The problem is not that it's annoying, the problem is that it's annoying for no value.  The case that it was supposed to handle is handled just fine without it.

So let me re-state the cons of this:

1) it adds no security
2) it breaks valid usage
3) it diverges from the upstream

I see no pros.  Do you?

--- Additional comment from Matthew Miller on 2014-02-24 12:14:04 EST ---

Particularly since we're deviating from the upstream default, I think the pro list ought to be pretty strong, but I'm not seeing it either. As noted in the first comment, that *stated* reason is not accurate.

--- Additional comment from Daniel Kopeček on 2014-02-25 05:42:03 EST ---

Ok, after re-reading the docs, it looks like i don't have any pros to write :] I'll remove the requiretty defaults and add a comment about the visiblepw option.

--- Additional comment from Matthew Miller on 2014-02-25 08:08:49 EST ---

(In reply to Daniel Kopeček from comment #7)
> Ok, after re-reading the docs, it looks like i don't have any pros to write
> :] I'll remove the requiretty defaults and add a comment about the visiblepw
> option.

Awesome -- thanks!

--- Additional comment from Matthew Miller on 2014-07-15 16:08:01 EDT ---

I'm going to close this bug, as it was fixed in march:

* Mon Mar 10 2014 Daniel Kopecek <dkopecek> - 1.8.8-3
- remove bundled copy of zlib before compilation
- drop the requiretty Defaults setting from sudoers

Comment 8 Aleksandar Kostadinov 2016-03-28 16:25:25 UTC
btw one other issue with `requiretty` is that ansible has much better performance when requiretty is off (for the pipelining option to work).

Also, as far as I can understand the link below, upstream is having requiretty turned *off* by default, and it would be nice to be the same:
https://www.sudo.ws/repos/sudo/file/cdbe432c465c/doc/sudoers.man.in

Comment 14 Daniel Kopeček 2016-05-09 11:27:33 UTC
Created attachment 1155247 [details]
proposed patch

Comment 17 Thom Carlin 2016-06-29 11:21:27 UTC
*** Bug 1350922 has been marked as a duplicate of this bug. ***

Comment 19 errata-xmlrpc 2016-11-03 20:31:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2593.html


Note You need to log in before you can comment on or make changes to this bug.