Bug 1350922 - default requiretty is problematic and breaks valid usage
Summary: default requiretty is problematic and breaks valid usage
Status: CLOSED DUPLICATE of bug 1196451
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sudo
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Daniel Kopeček
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Keywords:
Depends On: 1020147
Blocks: 1196451
TreeView+ depends on / blocked
 
Reported: 2016-06-28 17:49 UTC by Thom Carlin
Modified: 2016-06-29 11:21 UTC (History)
14 users (show)

(edit)
Clone Of: 1020147
(edit)
Last Closed: 2016-06-29 11:21:27 UTC


Attachments (Terms of Use)

Description Thom Carlin 2016-06-28 17:49:31 UTC
+++ This bug was initially created as a clone of Bug #1020147 +++

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@redhat.com> - 1.8.8-3
- remove bundled copy of zlib before compilation
- drop the requiretty Defaults setting from sudoers

NOTE: We encountered this in QCI 1.2

Comment 3 Thom Carlin 2016-06-29 11:21:27 UTC
my bad, duplicate of bz filed for RHEL-7.0.  Sorry for the noise.

*** This bug has been marked as a duplicate of bug 1196451 ***


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