Bug 1897566
| Summary: | [RFE] support ldapi URLs | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Graham Leggett <minfrin> |
| Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> |
| Status: | CLOSED UPSTREAM | QA Contact: | sssd-qe <sssd-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.4 | CC: | abokovoy, atikhono, grajaiya, jhrozek, lslebodn, mzidek, pbrezina, sbose, thalman, tscherf |
| Target Milestone: | rc | Keywords: | FutureFeature, Reopened, Triaged |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | sync-to-jira | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-08-30 17:52:36 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: | |||
|
Description
Graham Leggett
2020-11-13 13:09:42 UTC
Hi,
this is currently expected since SSSD only supports ldap and ldaps URIs. The sssd-ldap man page says
The format of the URI must match the format defined in RFC 2732:
ldap[s]://<host>[:port]
I agree this is not very explicit about what is support and what not.
It would be possible to add ldapi support but since this is a new feature it might take some time.
bye,
Sumit
In general, this is a valid RFE. It might have some sense to implement. For example for the case of SSSD running on IPA server. But at the moment this is not planned and we do not have ETA. I don't think we need this on IPA masters, sorry. This will only complicate things as SSSD is running as root and we have autobinding enabled and root mapped to cn=Directory Manager. > I don't think we need this on IPA masters, sorry.
To be clear, this need has nothing specifically to do with IPA.
The requirement is to get access to the file security model of unix domain sockets.
As it stands, this RFE has no sufficient explanation of the use case. 'Passwordless' access over UNIX domain socket is a broad request. It needs cooperation between the LDAP client and LDAP server (configuration-wise, at least). You are claiming it is not related to IPA -- what is the environment you are planning to use this feature in? How that can be configured and tested? If you really need this RFE, please write up a general description of the use case and the flows you expect to have. We evaluated this RFE and we think that it brings only little value. Also as mentioned before use-case is not very well defined. Considering this and our capacity we decided not to work on it. If you disagree with the decision please reopen this BZ with more details. However this does not guarantee that the request will not be closed during the triage as we are currently applying much more rigor to what we actually can accomplish in the foreseeable future. Contributions and collaboration in the upstream community and CentOS Stream is always welcome! Thank you for understanding Red Hat Enterprise Linux Identity Management Team To clarify. Security hardening is the practise of removing elements of a system that are open to abuse, the idea being you cannot attack what physically doesn't exist. Unix domain sockets are a way to communicate internally on the same machine, using the same internal users and groups to secure the connection that secure both the filesystem, and the process itself. Crucially, that allows one process to communicate with another process without using passwords or other credentials. LDAP in general, and 389ds specifically, has supported ldap-over-unix-domain-socket (ldapi scheme) for decades now. Systems like postfix, dovecot, and various milters all support unix domain sockets. What this means is that it is very easy to deploy a single hardened "unit" of services, all running on the same machine, all communicating with each other without using passwords at all. Except sssd. Sssd running on a given machine needs a password to connect to an LDAP server running on the same machine. This means a) a TCP socket is exposed, which is open to be abused, and b) passwords need to be instantiated, which is open to be abused. You cannot gain access to a unix domain socket outside a machine, you cannot steal or exploit a password that physically does not exist. Having looked in the sssd code, what I saw was an assumption being made that all connections start with a DNS lookup. Fixing this should be simple - if the scheme is ldapi, the path points at a filesystem path and not DNS. (In reply to Graham Leggett from comment #9) > > LDAP in general, and 389ds specifically, has supported > ldap-over-unix-domain-socket (ldapi scheme) for decades now. Systems like > postfix, dovecot, and various milters all support unix domain sockets. > > What this means is that it is very easy to deploy a single hardened "unit" > of services, all running on the same machine, all communicating with each > other without using passwords at all. > > Except sssd. > > Sssd running on a given machine needs a password to connect to an LDAP > server running on the same machine. This means a) a TCP socket is exposed, > which is open to be abused, and b) passwords need to be instantiated, which > is open to be abused. What is the use case of local-only (isolated from a network) LDAP server? If you only want to use those identities locally, why do you need LDAP server at all (instead of plain /etc/passwd, for example)? > What is the use case of local-only (isolated from a network) LDAP server?
> If you only want to use those identities locally, why do you need LDAP server at all (instead of plain /etc/passwd, for example)?
Turning the question on it's head, when you have an IMAP daemon, a POP daemon, an SMTP daemon, a webserver exposing various services like calendars etc, and an SSH daemon, why would you try and configure these against multiple backends (/etc/passwd, ldap, etc) when you can just integrate one service (ldap) and be done with it?
LDAP gives you the option to import/export data in an interoperable format, the option to become network accessible if you so choose, all in one system, why would you make your life difficult by turning one system into N systems?
sssd-ldap is the outlier at this stage, there seems to be no good reason I could find in the code for why ldapi was excluded.
It looks like opening discussion (or even better opening a PR) upstream is a best way to address this. This was re-evaluated within the team again and we are sorry but it can't make into our backlog. Patches are welcome upstream. |