#1555 validate the shell coming from the directory or the cache
Closed: wontfix 4 years ago by jhrozek. Opened 11 years ago by jhrozek.

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

Fields changed

milestone: SSSD 1.12 beta => SSSD 1.13 beta

Fields changed

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)

7 years ago

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

6 years ago

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.

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)

6 years ago

@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.

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)

4 years ago

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)

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/2597

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