On error, libnss_sss can mistakenly close descriptors it doesn't "own"

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2409

• Created at 2014-08-18 23:41:08 by nalin
• Closed as Fixed
• Assigned to nobody
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1118541

---

If sss_nss_mc_init_ctx() fails to open an mcache file (say, because it doesn't exist), at nss_mc_common.c:125, it jumps to the "done" label, which clears the passed-in sss_cli_mc_ctx structure and returns the error code which open() returned as the function's result.

When sss_nss_mc_init_ctx() returns, sss_nss_mc_get_ctx() compares the descriptor in the context (which has just been cleared, so it's 0) to -1, and then passes it to close(). In my case, it was closing standard input in 'tar', but it probably happens elsewhere, too.

Comments

---

Comment from simo at 2014-08-19 00:42:15

ouch!

priority: major => blocker

---

Comment from lslebodn at 2014-08-19 11:51:02

Nice catch.
By default, fd is initialized to -1.

src/sss_client/nss_mc_group.c:struct sss_cli_mc_ctx gr_mc_ctx = { false, -1, 0, NULL, 0, NULL, 0, NULL, 0 };
src/sss_client/nss_mc_passwd.c:struct sss_cli_mc_ctx pw_mc_ctx = { false, -1, 0, NULL, 0, NULL, 0, NULL, 0 };

This clean up section was there from beginning.

commit 5f216c753dbd2f2b25a011c5f705ee4f8ad924e6
Author: Simo Sorce <simo@redhat.com>
Date:   Mon Jan 2 15:33:16 2012 -0500

Nalin, could you attach git formatted patch or send it to sssd-devel?

---

Comment from lslebodn at 2014-08-19 11:56:44

I would like to know. How did you find this issue? because fd should have either initial value -1 or file descriptor opened by sssd-client code.

cc: => lslebodn@redhat.com

---

Comment from nalin at 2014-08-19 16:57:33

Replying to [comment:3 lslebodn]:

I would like to know. How did you find this issue? because fd should have either initial value -1 or file descriptor opened by sssd-client code.

The nightly IPA builds are built in under mock, which is in an environment where the client stubs are installed but SSSD has never been run. The builds were failing because tar, expecting to read the source tarball on stdin, was getting stdin closed out from under it after extracting only a couple of files (and attempting to look up their owners, falling over from 'files' to 'sss' per nsswitch.conf).

---

Comment from nalin at 2014-08-20 21:38:19

A patch which fixes it on my system, probably only one of several possible fixes.
close.patch

---

Comment from lslebodn at 2014-08-21 14:03:59

Fields changed

patch: 0 => 1

---

Comment from jhrozek at 2014-08-22 16:43:39

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1118541 (Red Hat Enterprise Linux 6)

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=1118541 1118541]

---

Comment from jhrozek at 2014-08-22 16:44:48

Thank you very much for the patch, Nalin.

• master: 5a4df83
• sssd-1-11: 49a73ff

milestone: NEEDS_TRIAGE => SSSD 1.11.7
resolution: => fixed
status: new => closed

---

Comment from nalin at 2017-02-24 14:48:28

Metadata Update from @nalin:

• Issue set to the milestone: SSSD 1.11.7