Bug 1020147

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.

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.

(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?

(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.

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?

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.

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.

(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!

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

> It adds no security

This is incorrect.  This -definitely- makes it harder for a local application without a tty to abuse sudoers if there is a 'shell like' environment that attackers may use.

Created attachment 1305084 [details]
Example of trivially bypassing requiretty

This provides a recipe for circumventing requiretty for the sake of running rsync on a target machine as root. All that's needed on the target machine is `bash`, `script` and `rsync`.

>> It adds no security

> This is incorrect.  This -definitely- makes it harder for a local application without a tty to abuse sudoers if there is a 'shell like' environment that attackers may use.

Wade, is there some angle I'm missing? Per my last attachment, it seems like requiretty is pretty trivial to side step, even for slightly nuanced scenarios (which, I think, the rsync case qualifies).