389-ds-base

#50890 Ticket 50889 - Extract pem files into a private namespace
Closed by spichugi. Opened by tbordaz.
tbordaz/389-ds-base Ticket-50889  into  master

Download 50890.patch

Bug Description:
since 1.3.5, certificates and keys are, by default, extracted under
nsslapd-certdir directory. They are exracted in pem files.

Some pem files (i.e. Serv-Cert-Key.pem) contain sensitive.
The ticket is to extract them into a private namespace specific
to the DS process.

Fix Description:
If the process is started with systemd, it uses the PrivateTmp=on
directive to create a private namespace.
Then if such private namespace exists and nsslapd-private-certdir is
defined withing the private namespace, DS extracts the certificates/keys
under nsslapd-private-certdir

https://pagure.io/389-ds-base/issue/50889

Reviewed by: ?

Platforms tested: F30

Doc impact: yes

Metadata Update from @tbordaz:
- Pull-request tagged with: WIP

rebased onto 0d79265002c9072cf755e89589912df1e0d938a4

rebased onto 379a43f7de55092937a42b509fe76ee9c43f1a7d

rebased onto a2e1cface7b1bf9bb4d5e8fa84de5a4ca2c1de83

All tests completed, I am removing WIP flag to get feedbacks
Things I am not comfortable with are the safety of private namespace and the way it is tested

Metadata Update from @tbordaz:
- Pull-request untagged with: WIP

Can I review this tomorrow? Sorry about the delay :(

rebased onto 3a248de3997232421a135c9ddfba34b14752aec1

What about existing servers on upgrade? I think we sohuldn't have this in the template, but we should make this a cn=config migration.

I don't know if this needs a cn=config attribute, I think your detection of the system private namespace is enough - if it exists we use that, if not we dont? I think the cn=config doesn't really serve a purpose here in that case .... is there some use case you had in mind?

Besides these comments the code looks good, I like the systemd private namespace detection :)

rebased onto 8d978b8860d8d31fc11ab82eb7e6fe9c6f6c6420

rebased onto 73611bd21a339a0993d6939c3836097d5959a84d

rebased onto 60ae321e75b6b3153ef71abd4879bf87e8db4efd

@firstyear after discussion with @lkrispen he convinced me that you were right :)

It is useless to introduce a new config parameter: Location of PEM file is internal thing and no reason to specify a path, If admin do need PEM it is always possible to extract key/cert (certutil), current location comes from historical reason and was not specified, adding a config param brings complexity without real added value.
Please have a look at the revisited patch.

looks really good :) ack from me :)

Pull-Request has been merged by tbordaz

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 pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3943

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.