#1342 Expose some shadow information to getent or other helper program
Closed: wontfix 4 years ago by pbrezina. Opened 11 years ago by pixie79.

We have custom scripts that need to evaluate some of the fields of a users shadow record.

Currently we do this directly to openldap but we are switching to SSSD and would like to use the local SSSD cache for this information.
Ideally all we need to know is:
- !ShadowExpire
- !ShadowLastChange
- !ShadowWarning
- !ShadowMax

This could either be via getent shadow ? or probably easier by a helper program / script that you can query for example

$ sssd-shadow userid
90 10 7 23456

This can then be easily used by other programs, it would also be secure enough that any user could call it as it does not expose anything sensitive.

Thanks

Mark


Fields changed

description: We have custom scripts that need to evaluate some of the fields of a users shadow record.

Currently we do this directly to openldap but we are switching to SSSD and would like to use the local SSSD cache for this information.
Ideally all we need to know is:
ShadowExpire
ShadowLastChange
ShadowWarning
ShadowMax

This could either be via getent shadow ? or probably easier by a helper program / script that you can query for example

$ sssd-shadow userid
90 10 7 23456

This can then be easily used by other programs, it would also be secure enough that any user could call it as it does not expose anything sensitive.

Thanks

Mark => We have custom scripts that need to evaluate some of the fields of a users shadow record.

Currently we do this directly to openldap but we are switching to SSSD and would like to use the local SSSD cache for this information.
Ideally all we need to know is:
* !ShadowExpire
* !ShadowLastChange
* !ShadowWarning
* !ShadowMax

This could either be via getent shadow ? or probably easier by a helper program / script that you can query for example

{{{
$ sssd-shadow userid
90 10 7 23456
}}}

This can then be easily used by other programs, it would also be secure enough that any user could call it as it does not expose anything sensitive.

Thanks

Mark

Supporting the shadow map will be the most compatible solution to this issue.

I disagree that this information does not expose anything sensitive, however. At the very least, it provides an attacker information about when a user may be changing their password (near its expiration). This may provide information about a window of opportunity (if a vulnerability during a password-change operation exists).

So at least in the first pass at this, we'll support the shadow map in its standard incarnation, being accessible only to root processes.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11 beta
priority: major => minor
rhbz: => todo

Fields changed

proposed_priority: => Optional

This ticket has been evaluated for inclusion into SSSD 1.10 release and was decided to be excluded since it does not match the main goals and themes of the release. It might be considered for later releases.

Fields changed

milestone: SSSD 1.11 beta => SSSD 1.12 beta

I'm sorry but we don't plan on implementing the shadow map unless patches are contributed.

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
mark: => 0
milestone: SSSD 1.14 beta => SSSD Deferred
review: => 0
selected: =>
sensitive: => 0

Metadata Update from @pixie79:
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2384

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata