Learn more about these different git repos.
Other Git URLs
It is possible to put junk into the shell attribute of an user entry. We should reuse the existing code that is in use when allowed_shells/vetoed_shells are present, check if the shell exists and at least give a warning.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.12 beta rhbz: => todo
milestone: SSSD 1.12 beta => SSSD 1.13 beta
changelog: => design: => design_review: => 0 fedora_test_page: => keywords: => easyfix mark: => 0 review: => 0 selected: => sensitive: => 0
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD Future releases (no date set yet)
Metadata Update from @jhrozek: - Custom field design_review reset (from 0) - Custom field mark reset (from 0) - Custom field patch reset (from 0) - Custom field review reset (from 0) - Custom field sensitive reset (from 0) - Custom field testsupdated reset (from 0) - Issue close_status updated to: None - Issue tagged with: easyfix
Do we expect to put an debug messages inside src/responder/common/responder_common.c after ret = confdb_get_string_as_list(cdb, rctx, CONFDB_NSS_CONF_ENTRY, CONFDB_NSS_ALLOWED_SHELL, &rctx->allowed_shells); ret = confdb_get_string_as_list(cdb, rctx, CONFDB_NSS_CONF_ENTRY, CONFDB_NSS_VETOED_SHELL, &rctx->vetoed_shells);
something as: if (rctx->allowed_shells && rctx->vetoed_shells) { DEBUG(SSSDBG_IMPORTANT_INFO,"Both allowed_shells & vetoed_shells are present"); }
This is not (I think..it's been 4 years since I opened this ticket) what the ticket is about. The ticket was about checking the LDAP attribute that contains the user's shell against either /etc/shells or more preferably also against the logic that is in sss_resp_get_shell_override and issue a warning.
sss_resp_get_shell_override
But re-reading the ticket, I'm no longer convinced it's all that useful. There is a ton of code that is responder-specific and moving all this to providers only in order to provide a warning seems like busywork.
You can send a mail to sssd-devel to also ask others, but in my opinion it can be just closed.
Metadata Update from @jhrozek: - Custom field design_review reset (from false) - Custom field mark reset (from false) - Custom field patch reset (from false) - Custom field review reset (from false) - Custom field sensitive reset (from false) - Custom field testsupdated reset (from false)
@jhrozek just wondering, do we still need this functionality or this issue can be closed? If we still need this functionality, I will probably work on it...
As I said earlier, I'm not sure this is needed. Nobody complained about the behaviour since the ticket was opened.
@jhrozek let's close it then :-)
Metadata Update from @jhrozek: - Custom field design_review adjusted to on (was: false) - Custom field mark adjusted to on (was: false) - Custom field patch adjusted to on (was: false) - Custom field review adjusted to on (was: false) - Custom field sensitive adjusted to on (was: false) - Custom field testsupdated adjusted to on (was: false) - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/2597
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.