Bug 976593 - Accept user password on command line.
Accept user password on command line.
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: realmd (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stef Walter
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 985817
  Show dependency treegraph
 
Reported: 2013-06-20 20:00 EDT by David Woodhouse
Modified: 2015-02-18 06:12 EST (History)
4 users (show)

See Also:
Fixed In Version: realmd-0.14.3-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 985817 (view as bug list)
Environment:
Last Closed: 2015-02-18 06:12:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
service: Support use of kerberos ccache to join when using winbind (810 bytes, patch)
2013-07-02 08:51 EDT, Stef Walter
no flags Details | Diff
If input is not a tty, then just read from stdin without getpass() (2.05 KB, patch)
2013-07-19 11:01 EDT, Stef Walter
no flags Details | Diff
tools: Add an --unattended argument to realm command line client (2.51 KB, patch)
2013-07-24 10:55 EDT, Stef Walter
no flags Details | Diff

  None (edit)
Description David Woodhouse 2013-06-20 20:00:14 EDT
I have a firstboot module (which I need to update to initial-setup in Fedora 19) which joins a machine to our corporate domain and sets it up.

It asks the user for their domain name, username, password and the hostname, and then it performs all the setup, including obtaining SSL certs from our internal PKI infrastructure for VPN and wireless, performing Exchange autodiscover and provisioning the EWS account in Evolution, etc.

However, there is an issue in invoking 'realm join', because it uses the deprecated getpass() function to obtain the password.

Life would be so much easier if I could just pass the password in on the command line. By definition, this is *before* there are untrusted users on the box so there is no security issue with it being visible on the command line.

If I have no controlling TTY, getpass() will at least read it from stdin, so for testing my scripts I can use something like this:

#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char **argv)
{
	int fd = open("/dev/tty", O_RDONLY);
	if (fd != -1) {
		ioctl(fd, TIOCNOTTY, NULL);
		close(fd);
	}
	execv("/sbin/realm", argv);	
}

But still I have to feed it in on stdin and I also need to filter the 'Password for $USER' prompt out of the output which I'm displaying.
Comment 1 Stef Walter 2013-06-21 08:31:27 EDT
The best way to pass a password to the realm client is via kerberos and kinit. kinit for your, and then run realm join xxxx.

The above doesn't work for NTLM, so I can see why there would be a use case for accepting a password in a way that is easier to use from scripts.

I think that having an option like --stdin-password (like what adcli does) is the best way to accomplish this. Would you be interested in putting together such a patch?
Comment 2 David Woodhouse 2013-06-21 09:04:48 EDT
It *could* work for NTLM. You could make it invoke /usr/bin/ntlm_auth like other NTLM clients do.

But Kerberos is fine for me; thanks. Having a --stdin-password would still be nice, but I have far more fundamental things to be looking at if I'm to use SSSD for our corporate clients. Like actually having it accept my user password reliably when I attempt to log in.
Comment 3 David Woodhouse 2013-07-01 03:48:27 EDT
Hm, I take it back. It looks like I'm going to have to use winbind for now. Our environment *really* needs the NTLM fallback, since that's what Windows does so people never *notice* when DNS and other issues make Kerberos break. So SSSD isn't going to work for us yet.

And the Kerberos auth doesn't seem to be working with winbind from realmd. If I run 'net -k ads join...' manually it does.

Although I note it gives s crappy error if I *don't* have a TGT:

[root@shinybook scripts]# net -k ads join ger.corp.intel.com
Failed to join domain: failed to lookup DC info for domain 'ger.corp.intel.com' over rpc: Undetermined error
[root@shinybook scripts]# kinit dwoodhou
Password for dwoodhou@GER.CORP.INTEL.COM: 
[root@shinybook scripts]# net -k ads join ger.corp.intel.com
Using short domain name -- GER
Joined 'DWOODHOU-MOBL5' to dns domain 'ger.corp.intel.com'
Comment 4 Stef Walter 2013-07-01 15:20:32 EDT
(In reply to David Woodhouse from comment #3)
> Hm, I take it back. It looks like I'm going to have to use winbind for now.
> Our environment *really* needs the NTLM fallback, since that's what Windows
> does so people never *notice* when DNS and other issues make Kerberos break.
> So SSSD isn't going to work for us yet.
> 
> And the Kerberos auth doesn't seem to be working with winbind from realmd.
> If I run 'net -k ads join...' manually it does.

What does the 'realm --verbose' output say?
Comment 5 David Woodhouse 2013-07-01 15:47:01 EDT
[root@dwoodhou-mobl3 ~]# realm join --client-software=winbind ger.corp.intel.com -v
 * Resolving: _ldap._tcp.ger.corp.intel.com
 * Performing LDAP DSE lookup on: 10.31.1.128
 * Performing LDAP DSE lookup on: 10.22.226.110
 * Performing LDAP DSE lookup on: 10.19.8.6
 * Successfully discovered: ger.corp.intel.com
Password for Administrator: 
 * Required files: /usr/libexec/oddjob/mkhomedir, /usr/sbin/oddjobd, /usr/bin/wbinfo, /usr/sbin/winbindd, /usr/bin/net
 * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.A2BLZW -U Administrator ads join ger.corp.intel.com
^CCancelling...
Comment 6 David Woodhouse 2013-07-01 15:47:23 EDT
[root@dwoodhou-mobl3 ~]# realm join --client-software=winbind -U dwoodhou ger.corp.intel.com -v
 * Resolving: _ldap._tcp.ger.corp.intel.com
 * Performing LDAP DSE lookup on: 10.22.226.110
 * Performing LDAP DSE lookup on: 10.31.1.128
 * Performing LDAP DSE lookup on: 10.19.8.6
 * Successfully discovered: ger.corp.intel.com
Password for dwoodhou: 
 * Required files: /usr/libexec/oddjob/mkhomedir, /usr/sbin/oddjobd, /usr/bin/wbinfo, /usr/sbin/winbindd, /usr/bin/net
 * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.SOEKZW -U dwoodhou ads join ger.corp.intel.com
Enter dwoodhou's password:
^CCancelling...
Comment 7 David Woodhouse 2013-07-01 15:48:25 EDT
Note the 'Password for...' prompts which I don't seem to be able to cancel, which is why they aren't the last line in the output each time.
Comment 8 Stef Walter 2013-07-02 08:51:50 EDT
Created attachment 767718 [details]
service: Support use of kerberos ccache to join when using winbind

David, does this patch allow you to join using winbind + kerberos credentials?
Comment 9 David Woodhouse 2013-07-18 06:33:20 EDT
Apologies for delayed response.

Yes that patch works for the successful case. However, the failure mode when I fail to set the system hostname correctly (it doesn't normally match the 'netbios name' in my smb.conf) is not quite right. It still demands a password then, when presumably it should fail cleanly?

 * Resolving: _ldap._tcp.ger.corp.intel.com
 * Performing LDAP DSE lookup on: 10.22.226.110
 * Performing LDAP DSE lookup on: 10.19.8.6
 * Performing LDAP DSE lookup on: 10.217.64.7
 * Successfully discovered: ger.corp.intel.com
 * Required files: /usr/libexec/oddjob/mkhomedir, /usr/sbin/oddjobd, /usr/bin/wbinfo, /usr/sbin/winbindd, /usr/bin/net
 * LANG=C KRB5CCNAME=/var/cache/realmd/realm-ad-kerberos-575C0W /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.K56C0W -k ads join ger.corp.intel.com
Failed to join domain: User specified does not have administrator privileges
 ! Insufficient permissions to join the domain ger.corp.intel.com
Password for Administrator:
Comment 10 Stef Walter 2013-07-19 11:01:25 EDT
Created attachment 775840 [details]
If input is not a tty, then just read from stdin without getpass()

This allows people to echo passwords into the realm client command
like this:

echo "password" | realm join --user Administrator example.com
Comment 11 Stef Walter 2013-07-19 11:03:07 EDT
(In reply to David Woodhouse from comment #9)
> Apologies for delayed response.
> 
> Yes that patch works for the successful case. However, the failure mode when
> I fail to set the system hostname correctly (it doesn't normally match the
> 'netbios name' in my smb.conf) is not quite right. It still demands a
> password then, when presumably it should fail cleanly?

Should we have a --no-password argument to prevent prompting for passwords?
Comment 12 Stef Walter 2013-07-19 12:19:34 EDT
(In reply to Stef Walter from comment #10)
> If input is not a tty, then just read from stdin without getpass()

Tested this patch and pushed to realmd git master.

kerberos joins + winbind was tested by David, also pushed to realmd git master.
Comment 13 David Woodhouse 2013-07-22 10:43:09 EDT
(In reply to Stef Walter from comment #11)
> Should we have a --no-password argument to prevent prompting for passwords?

That would make sense, perhaps. Or a '-k' option like Samba's. Not asking for a password should be implicit, if you were *asked* to do Kerberos auth.
Comment 14 Stef Walter 2013-07-24 10:55:39 EDT
Created attachment 777836 [details]
tools: Add an --unattended argument to realm command line client

David, could you try out this patch? Does it solve the issue for
you?
Comment 15 Stef Walter 2013-08-07 04:09:20 EDT
Attachment 777836 [details] pushed as 206a320 - tools: Add an --unattended argument to realm command line client
Comment 16 Stef Walter 2013-08-14 11:19:48 EDT
Caused regression: https://bugs.freedesktop.org/show_bug.cgi?id=68112
Comment 17 Fedora End Of Life 2015-01-09 17:34:33 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 18 Fedora End Of Life 2015-02-18 06:12:24 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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