On Fri, Feb 23, 2024 at 12:06 PM John Doe <jdoe53...@gmail.com> wrote:
> Now I know I can calculate the time for expiration myself by > checking the 'offline_credentials_expiration' value in sssd.conf and > add that to the timestamp for cache entry last update time reported > by 'sudo sssctl user-show $USER' Are you certain of that? In my testing, the timestamps shown by "sssctl user-show $USER" would change if sssd was in an online state and refreshed the user object from AD; no authentication was required. And while it is probably the case that if sssd was online for any significant period of time, the user probably authenticated during that time (e.g., unlocking a screen saver would count) and thus the cached password expiration was updated, you cannot necessarily assume that. My conclusion was that while sssd (obviously) has code paths to look up the cached password expiration, they are reached only through the PAM stack. There is no generic way (e.g., via sssctl) to discover what credentials are cached within sssd, or when those credentials expire. Similarly, there appears to be no way to list all Kerberos credentials stored in KCM. If you suspect a specific user has credentials, you can setpriv(1) to that user and run klist(1), but there is no generic way to enumerate all credentials. > I was thinking of 'sss_cache' as that can run as a regular user but > that can't give me the timestamp :-( At least for Kerberos credentials, I once threw together a proof-of-concept script that used the Samba tdbdump utility to dump /var/lib/sss/secrets/secrets.ldb and rummage through the output, As great as sssd is, its opacity about its cached information is frustrating to system administrators. We shouldn’t need to resort to third-party data dumping tools to get useful information out of sssd. Thus, I would really love to see the following sssctl commands: * cred-show Information about cached user credentials * kcm-show Information about cached KCM credentials The "sssctl cred-show" command would produce a table of all cached user credentials, where the first column is the user@DOMAIN who owns the credentials, and the second column is the expiration time of credential expressed as time_t (seconds since epoch). The "sssctl kcm-show" command would product a similar table, with four columns: the owning user, the credential cache name, the credential, and the expiration time expressed as time_t. On Mon, Feb 26, 2024 at 6:40 AM Alexey Tikhonov <atikh...@redhat.com> wrote: > *sorry, `CAP_DAC_OVERRIDE`, of course. CAP_DAC_READ_SEARCH would be better, as unlike CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH does not bypass file *write* permission checks. But even still, this is arguably a flawed approach, as depending on how this is implemented, you might wind up exposing the complete contents of the /var/lib/sss/secrets/secrets.ldb file to ordinary users. Among other things, that would allow theft of KCM credentials, and harvesting any/all cached credentials for nefarious purposes (e.g. offline password cracking). The best long-term approach would be for sssctl to add commands that permit enumeration of cached credentials (and cached KCM credentials). From there, any number of scripting solutions are possible. -- _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
