RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1872451 - [RFE] 389ds: run as non-root
Summary: [RFE] 389ds: run as non-root
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: 389-ds-base
Version: 9.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: beta
: 9.1
Assignee: Pierre Rogier
QA Contact: RHDS QE
Evgenia Martynyuk
URL:
Whiteboard: sync-to-jira
: 2126614 (view as bug list)
Depends On:
Blocks: 2091421 2132697
TreeView+ depends on / blocked
 
Reported: 2020-08-25 18:27 UTC by Robbie Harwood
Modified: 2022-12-07 14:42 UTC (History)
16 users (show)

Fixed In Version: 389-ds-base-2.1.3-4.el9_1
Doc Type: Enhancement
Doc Text:
.Directory Server now supports instance creation by a non-root user Previously, non-root users were not able to create Directory Server instances. With this enhancement, a non-root user can use the `dscreate ds-root` subcommand to configure an environment where `dscreate`,`dsctl`,`dsconf` commands are used as usual to create and administer Directory Server instances.
Clone Of:
: 2132697 (view as bug list)
Environment:
Last Closed: 2022-11-15 10:30:16 UTC
Type: Bug
Target Upstream Version:
Embargoed:
emartyny: needinfo+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 5217 0 None open Simplify instance creation and administration by non root user 2022-03-18 20:07:49 UTC
Red Hat Issue Tracker IDMDS-2268 0 None None None 2022-05-09 08:53:46 UTC
Red Hat Knowledge Base (Solution) 6232791 0 None None None 2021-08-03 12:27:35 UTC
Red Hat Product Errata RHSA-2022:8162 0 None None None 2022-11-15 10:31:04 UTC

Description Robbie Harwood 2020-08-25 18:27:30 UTC
openldap's server supports running as non-root.  This enables us to easily use it in test suites - for instance, when testing gssproxy, `make check` can set up a KDC with openldap backend as whatever user.  (This then of course works in CI, which just runs `make check`.)

It's my understanding that 389ds doesn't support this kind of operation.  So since the openldap server isn't in RHEL, it means our tests are dependent on EPEL (or else can't really run those parts, which are some of the most important to test due to their complexity).

Upstream gssproxy ticket for migration is https://github.com/gssapi/gssproxy/issues/8

Comment 3 Viktor Ashirov 2020-10-13 09:53:55 UTC
To clarify: this is not about ns-slapd itself running as non-root but about the tooling (dscreate/lib389) to support installations under non-root users.
There is already support for this kind of thing: `dscreate create-template` can generate a template where user/group, locations can be adjusted, selinux and systemd support can be turned off. 
For example, my.ini:

[general]
selinux = False
start = False
strict_host_checking = False
systemd = False

[slapd]
backup_dir = /home/vashirov/ds/var/lib/dirsrv/slapd-{instance_name}/bak
bin_dir = /usr/bin
cert_dir = /home/vashirov/ds/etc/dirsrv/slapd-{instance_name}
config_dir = /home/vashirov/ds/etc/dirsrv/slapd-{instance_name}
data_dir = /usr/share
db_dir = /home/vashirov/ds/var/lib/dirsrv/slapd-{instance_name}/db
db_home_dir = /home/vashirov/ds/var/lib/dirsrv/slapd-{instance_name}/db
group = vashirov
initconfig_dir = /home/vashirov/ds/etc/sysconfig
inst_dir = /home/vashirov/ds/usr/lib64/dirsrv/slapd-{instance_name}
instance_name = localhost
ldif_dir = /home/vashirov/ds/var/lib/dirsrv/slapd-{instance_name}/ldif
lib_dir = /usr/lib64
local_state_dir = /home/vashirov/ds/var
lock_dir = /home/vashirov/ds/var/lock/dirsrv/slapd-{instance_name}
log_dir = /home/vashirov/ds/var/log/dirsrv/slapd-{instance_name}
port = 33389
prefix = /usr
root_dn = cn=Directory Manager
root_password = password
run_dir = /home/vashirov/ds/var/run/dirsrv
sbin_dir = /usr/sbin
schema_dir = /home/vashirov/ds/etc/dirsrv/slapd-{instance_name}/schema
secure_port = 33636
self_sign_cert = True
self_sign_cert_valid_months = 24
sysconf_dir = /home/vashirov/ds/etc
tmp_dir = /home/vashirov/ds/tmp
user = vashirov

[backend-userroot]
create_suffix_entry = True
;require_index = False
sample_entries = yes
suffix = dc=example,dc=com

I had to create some directories first with config files (this should also be addressed):
[vashirov@ci-vm-10-0-139-99 ~]$ mkdir -p /home/vashirov/ds/etc/dirsrv/schema
[vashirov@ci-vm-10-0-139-99 ~]$ mkdir -p /home/vashirov/ds/etc/dirsrv/config/
[vashirov@ci-vm-10-0-139-99 ~]$ cp /etc/dirsrv/config/* /home/vashirov/ds/etc/dirsrv/config/

[vashirov@ci-vm-10-0-139-99 ~]$ dscreate -v from-file my.ini
DEBUG: The 389 Directory Server Creation Tool
DEBUG: Inspired by works of: ITS, The University of Adelaide
DEBUG: Called with: Namespace(dryrun=False, file='my.ini', func=<function instance_create at 0x7f3617079488>, verbose=True)
DEBUG: Running setup with verbose
DEBUG: Using inf from my.ini
DEBUG: Configuration ['general', 'slapd', 'backend-userroot']
DEBUG: general:config_version not in inf, using default
DEBUG: general:full_machine_name not in inf, using default
DEBUG: general:defaults not in inf, using default
DEBUG: Configuration general {'config_version': 2, 'full_machine_name': 'ci-vm-10-0-139-99.hosted.upshift.rdu2.redhat.com', 'strict_host_checking': False, 'selinux': False, 'systemd': False, 'start': False, 'defaults': '999999999'}
DEBUG: Configuration slapd {'root_password': 'password', 'port': 33389, 'self_sign_cert_valid_months': 24, 'self_sign_cert': True, 'root_dn': 'cn=Directory Manager', 'user': 'vashirov', 'initconfig_dir': '/home/vashirov/ds/etc/sysconfig', 'group': 'vashirov', 'instance_name': 'localhost', 'secure_port': 33636, 'prefix': '/usr', 'bin_dir': '/usr/bin', 'sbin_dir': '/usr/sbin', 'sysconf_dir': '/home/vashirov/ds/etc', 'data_dir': '/usr/share', 'local_state_dir': '/home/vashirov/ds/var', 'lib_dir': '/usr/lib64', 'cert_dir': '/home/vashirov/ds/etc/dirsrv/slapd-localhost', 'config_dir': '/home/vashirov/ds/etc/dirsrv/slapd-localhost', 'inst_dir': '/home/vashirov/ds/usr/lib64/dirsrv/slapd-localhost', 'backup_dir': '/home/vashirov/ds/var/lib/dirsrv/slapd-localhost/bak', 'db_dir': '/home/vashirov/ds/var/lib/dirsrv/slapd-localhost/db', 'db_home_dir': '/home/vashirov/ds/var/lib/dirsrv/slapd-localhost/db', 'ldif_dir': '/home/vashirov/ds/var/lib/dirsrv/slapd-localhost/ldif', 'lock_dir': '/home/vashirov/ds/var/lock/dirsrv/slapd-localhost', 'log_dir': '/home/vashirov/ds/var/log/dirsrv/slapd-localhost', 'run_dir': '/home/vashirov/ds/var/run/dirsrv', 'schema_dir': '/home/vashirov/ds/etc/dirsrv/slapd-localhost/schema', 'tmp_dir': '/home/vashirov/ds/tmp'}
DEBUG: backend-userroot:require_index not in inf, using default
DEBUG: Configuration backends [{'name': 'userroot', 'suffix': 'dc=example,dc=com', 'create_suffix_entry': 'True', 'sample_entries': '999999999'}]
DEBUG: START: Starting installation...
DEBUG: READY: Preparing installation for localhost...
DEBUG: PASSED: using config settings 999999999
DEBUG: PASSED: user / group checking
DEBUG: PASSED: prefix checking
DEBUG: list instance not found in /etc/dirsrv/slapd-localhost/dse.ldif: localhost

DEBUG: PASSED: instance checking
DEBUG: INFO: temp root password set to 76OIv3gKqgKTSavpTyc2hSCttegj1kLIWS9YicOqtxfbds.SjUCjZZgu1lIkRfcFu
DEBUG: PASSED: root user checking
DEBUG: PASSED: network avaliability checking
DEBUG: READY: Beginning installation for localhost...
DEBUG: ACTION: Creating dse.ldif
DEBUG: ACTION: creating /home/vashirov/ds/var/lib/dirsrv/slapd-localhost/bak
DEBUG: ACTION: creating /home/vashirov/ds/etc/dirsrv/slapd-localhost
DEBUG: ACTION: creating /home/vashirov/ds/var/lib/dirsrv/slapd-localhost/db
DEBUG: ACTION: creating /home/vashirov/ds/var/lib/dirsrv/slapd-localhost/ldif
DEBUG: ACTION: creating /home/vashirov/ds/var/lock/dirsrv/slapd-localhost
DEBUG: ACTION: creating /home/vashirov/ds/var/log/dirsrv/slapd-localhost
DEBUG: ACTION: creating /home/vashirov/ds/var/run/dirsrv
DEBUG: ACTION: Creating certificate database is /home/vashirov/ds/etc/dirsrv/slapd-localhost
DEBUG: Allocate <class 'lib389.DirSrv'> with None
DEBUG: Allocate <class 'lib389.DirSrv'> with ci-vm-10-0-139-99.hosted.upshift.rdu2.redhat.com:33389
DEBUG: Allocate <class 'lib389.DirSrv'> with ci-vm-10-0-139-99.hosted.upshift.rdu2.redhat.com:33389
DEBUG: list instance not found in /etc/dirsrv/slapd-localhost/dse.ldif: localhost

DEBUG: Instance failed to install, does not exist when expected
Traceback (most recent call last):
  File "/usr/sbin/dscreate", line 75, in <module>
    result = args.func(inst, log, args)
  File "/usr/lib/python3.6/site-packages/lib389/cli_ctl/instance.py", line 68, in instance_create
    if sd.create_from_inf(args.file):
  File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line 537, in create_from_inf
    self.create_from_args(general, slapd, backends, self.extra)
  File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line 673, in create_from_args
    self._install_ds(general, slapd, backends)
  File "/usr/lib/python3.6/site-packages/lib389/instance/setup.py", line 848, in _install_ds
    assert_c(ds_instance.exists(), "Instance failed to install, does not exist when expected")
  File "/usr/lib/python3.6/site-packages/lib389/utils.py", line 1232, in assert_c
    raise AssertionError(msg)
AssertionError: Instance failed to install, does not exist when expected
ERROR: Error: Instance failed to install, does not exist when expected

Comment 7 mreynolds 2021-08-03 14:24:14 UTC
Arya,

This RFE has not been fully looked into yet, but this is about installing DS as a non-root user (the user/group the server runs as).   Only root user can install DS into the default location, so non-root install MUST be installed in a unique location where root privileges are not required.  So to answer your question, yes, it will support custom locations as it must be a custom location for it to work :)

Comment 8 mreynolds 2021-08-03 14:31:29 UTC
(In reply to mreynolds from comment #7)
> Arya,
> 
> This RFE has not been fully looked into yet, but this is about installing DS
> as a non-root user (the user/group the server runs as) 

Sorry this ^^^ was supposed to say:  (not the user/group the server runs as)

Comment 23 Viktor Ashirov 2022-09-14 11:38:27 UTC
This introduced a regression to `dscreate create-template`. It was fixed in https://github.com/389ds/389-ds-base/commit/45af34013f8bdd34f939d36b16776413e13c0a51

Moving to ASSIGNED.

Comment 28 mreynolds 2022-09-21 19:16:38 UTC
(In reply to Viktor Ashirov from comment #23)
> This introduced a regression to `dscreate create-template`. It was fixed in
> https://github.com/389ds/389-ds-base/commit/
> 45af34013f8bdd34f939d36b16776413e13c0a51
> 
> Moving to ASSIGNED.

Pierre, can you look into this regression?

Comment 29 Pierre Rogier 2022-09-22 11:50:07 UTC
The regression fix is in main branch and 2.2 but was not in 2.1 nor 2.0 (and 1.4.3 was not impacted )

So I cherry picked it to 2.1 and 2.0:
   42fa04d67..45af34013  main -> main
   42fa04d67..45af34013  389-ds-base-2.2 -> 389-ds-base-2.2
   7e1d99182..aa7fb1d39  389-ds-base-2.1 -> 389-ds-base-2.1
   4a7dbb44e..31aa1c8fc  389-ds-base-2.0 -> 389-ds-base-2.0

Not sure if the RFE and its regression is in RHEL 9.0/9.1 builds or not ...

Comment 30 Viktor Ashirov 2022-10-05 09:09:39 UTC
It affects 9.1, issue is present in 389-ds-base-2.1.3-3.el9.x86_64
It doesn't affect 9.0.
Patch is available upstream, moving to POST.

Comment 36 bsmejkal 2022-10-07 14:13:26 UTC
Per comment #c35 marking as VERIFIED.

Comment 37 bsmejkal 2022-10-13 15:35:23 UTC
*** Bug 2126614 has been marked as a duplicate of this bug. ***

Comment 43 Evgenia Martynyuk 2022-11-03 18:05:16 UTC
@jvilicic has kindly adreed to review RN text.

Thanks you!

DocText is updated. Now the RN is release pending

Comment 45 errata-xmlrpc 2022-11-15 10:30:16 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: 389-ds-base security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:8162


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