Bug 1872451
Summary: | [RFE] 389ds: run as non-root | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | Robbie Harwood <rharwood> | |
Component: | 389-ds-base | Assignee: | Pierre Rogier <progier> | |
Status: | CLOSED ERRATA | QA Contact: | RHDS QE <ds-qe-bugs> | |
Severity: | unspecified | Docs Contact: | Evgenia Martynyuk <emartyny> | |
Priority: | high | |||
Version: | 9.0 | CC: | arajendr, bsmejkal, gfialova, jvilicic, ldap-maint, mreynolds, omoris, pasik, pcech, progier, pvlasin, radrao, sgouvern, spichugi, tbordaz, vashirov | |
Target Milestone: | beta | Keywords: | FutureFeature, Regression, Triaged | |
Target Release: | 9.1 | Flags: | emartyny:
needinfo+
|
|
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | sync-to-jira | |||
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.
|
Story Points: | --- | |
Clone Of: | ||||
: | 2132697 (view as bug list) | Environment: | ||
Last Closed: | 2022-11-15 10:30:16 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 2091421, 2132697 |
Description
Robbie Harwood
2020-08-25 18:27:30 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 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 :) (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) This introduced a regression to `dscreate create-template`. It was fixed in https://github.com/389ds/389-ds-base/commit/45af34013f8bdd34f939d36b16776413e13c0a51 Moving to ASSIGNED. (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? 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 ... 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. Per comment #c35 marking as VERIFIED. *** Bug 2126614 has been marked as a duplicate of this bug. *** @jvilicic has kindly adreed to review RN text. Thanks you! DocText is updated. Now the RN is release pending 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 |