#50380 Use pwdfile from .dsrc for dsidm/dsconf
Opened 4 months ago by mgrobelin. Modified 4 months ago

Issue Description

The dsidm/dsconf command accepts -y/--pwdfile option to provide a bind-password, which is great for automation.

It is currently not possible to pass this option by a .dsrc file, so I must set it for all the CLI commands.

dsidm -y /root/.dsrcpw DS1 account list
dsidm -y /root/.dsrcpw DS1 user create
dsidm -y /root/.dsrcpw DS1 group add_member dsidmgroup uid=dsidmuser,ou=People,dc=corp,dc=net

I want to omit the option from the CLI commands, if set within .dsrc by pwdfile, to remove redundancy and increase readability in my scripts and docs.

Package Version and Platform

389-ds-base-1.4.1.2-2.fc30.x86_64

Steps to reproduce

  1. Create a .dsrc file like so:
[DS1]
uri = ldap://127.0.0.1:389
basedn = dc=corp,dc=net
binddn = cn=Directory Manager
pwdfile = /root/.dsrcpw
  1. Create /root/.dsrcpw including the bind password
  2. Try passwordless dsidm/dsconf commands, omit -y/--pwdfile option, e.g. dsidm DS1 user get dsidmuser

Actual results

It prompts for a password from stdin, because pwdfile from .dsrc is not recognized.

Expected results

The command should be executed, using the password I provided by the pwdfile directive within /root/.dsrc


Metadata Update from @mreynolds:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Issue set to the milestone: 1.4.0

4 months ago

I feel like Firstyear-of-the-past had a reason not to put in a password field into .dsrc, but I honestly don't remember what it was, so I think this is a good idea to improve. I suspect it may have been something like wanting to prevent un-attended attacks or people running commands without a prompt for input to accept of some form...

My main design question is if it should be a seperate pwdfile or if we should have the password in the .dsrc. One side, simplicity means having it all in the .dsrc is good. But another side is that having it split out means you can share the .dsrc and drop in the pwdfile as needed. To be clear - I think there should only be one method, so we should choose wisely now :)

Thoughts - @spichugi ?

If, then pwdfile, definitely not directly in .dsrc. .ldaprc/ldap.conf don't have this option due to security; the same goes e.g. with SSH's config where you're forced to options other than password. Additionally, I would require the file to be secure enough by a mode, e.g. 0600 like SSH does for private keys.

May I point to Postgresql .pgpass and MariaDB/MySQL .my.cnf? Both are capable to provide credentials and connection details to clients.

The security issue I am aware of is that storing cleartext passwords isn't ideal. But same already is the case for /etc/dirsrv/pin.txt or - as you named it - unencrypted SSH private keys.

Maybe dsidm could accept the hashed password in either .dsrc (or pwdfile)?

[DS1]
uri = ldap://127.0.0.1:389
basedn = dc=corp,dc=net
binddn = cn=Directory Manager
pwhash = PBKDF2_SHA256....

Maybe dsidm could accept the hashed password in either .dsrc (or pwdfile)?
[DS1]
uri = ldap://127.0.0.1:389
basedn = dc=corp,dc=net
binddn = cn=Directory Manager
pwhash = PBKDF2_SHA256....

Unfortunately this is not an option. You can not pass a hashed password value as the credentials. The server will attempt to re-hash that "hashed" password to compare it to the hashed password stored in the entry. It just won't work, nor should it.

I feel like Firstyear-of-the-past had a reason not to put in a password field into .dsrc, but I honestly don't remember what it was, so I think this is a good idea to improve. I suspect it may have been something like wanting to prevent un-attended attacks or people running commands without a prompt for input to accept of some form...
My main design question is if it should be a seperate pwdfile or if we should have the password in the .dsrc. One side, simplicity means having it all in the .dsrc is good. But another side is that having it split out means you can share the .dsrc and drop in the pwdfile as needed. To be clear - I think there should only be one method, so we should choose wisely now :)
Thoughts - @spichugi ?

I agree with @mhonek. I think it is better to store it in a separate file with a path in pwdfile.
It'll be more secure and still convenient.

I think the greatest lie ever told was that unix file permissions are secure ... these days getting any access to a linux machine is equivalent to root, and arguable, if you have access, you have to have root to actually be able to work on the machine anyway ....

Regardless. I think there are benefits to the password being in a seperate file, mainly that it allows a global or common dsrc if we ever implement it which then all users could inherit and have a personalise .dsrc.pw or something. Perhaps even to extend this it could actually be .dscreds which has the binddn + pw? That way it really is detached from the dsrc config?

Do you want to do this @mhonek or @spichugi ? Or should I take a look at this? Happy either way :)

Login to comment on this ticket.

Metadata