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 :)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3439

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.