Bug 473970 - pam_filter does not work in Red Hat EL5
pam_filter does not work in Red Hat EL5
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Tomas Mraz
Depends On:
  Show dependency treegraph
Reported: 2008-12-01 11:57 EST by Olivier Fourdan
Modified: 2013-03-03 21:47 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 07:24:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch that implements the fixes mentionned (5.30 KB, patch)
2008-12-01 11:57 EST, Olivier Fourdan
no flags Details | Diff
Updated patch (4.85 KB, patch)
2008-12-02 05:15 EST, Olivier Fourdan
no flags Details | Diff

  None (edit)
Description Olivier Fourdan 2008-12-01 11:57:14 EST
Created attachment 325258 [details]
Patch that implements the fixes mentionned

Description of problem:

pam_filter does not work on Red Hat Enterprise Linux 5 for several reasons.

Version-Release number of selected component (if applicable):


How reproducible:

100% reproducible

Steps to Reproduce:
1. Try the example from pam_filter man page.
   Add the following line to "/etc/pam.d/su" for example
   session required pam_filter.so run1 /lib/security/pam_filter/upperLOWER
3. Use “su” to become some user
Actual results:

# su someuser
could not open session

/var/log/secure shows:

Dec 10 11:46:50 rhel5 su: pam_filter(su:session): unknown pseudo terminal: /dev/ptyp0
Dec 10 11:46:50 rhel5 su: pam_filter(su:session): no master terminal

Expected results:

# su someuser

Additional info:

There seems to be more than one problem:

1) The pseudo-terminal was using the old BSD-style instead of the standard Unix-98 API.

2) The filter was using internal read/write routines. Reverting to the system read/write was still not enough, select() in the filter was failing on “stdin” file descriptor.

3) Avoid closing the fd[1] in the parent process fixes the issue with select on “stdin” in the filter.

The patch attached implements the following fixes and seem to work fine.

Note: This bug also affects upstream and should be also reported upstream. I can provide the same patch for Linux-PAM-1.0.2 (latest available at this time of writing)
Comment 1 Tomas Mraz 2008-12-01 13:32:39 EST
Why did you change the pam_modutil_read/write to regular read/write? Is it really necessary?
Comment 2 Olivier Fourdan 2008-12-02 05:15:14 EST
Created attachment 325349 [details]
Updated patch


(In reply to comment #1)
> Why did you change the pam_modutil_read/write to regular read/write? Is it
> really necessary?

Yes, actually, it is otherwise the filter just hangs. Basically, pam_modutil_read() will loop until it receives the buffer of data that they expect, or the read() fails:

     13 int
     14 pam_modutil_read(int fd, char *buffer, int count)
     15 {
     16        int block, offset = 0;
     18        while (count > 0) {
     19                block = read(fd, &buffer[offset], count);
     21                if (block < 0) {
     22                        if (errno == EINTR) continue;
     23                        return block;
     24                }
     25                if (block == 0) return offset;
     27                offset += block;
     28                count -= block;
     29        }
     31        return offset;
     32 }

As the buffer size is 8192, this breaks the filter will hang waiting for data (the data received is much smaller that the buffer size).

Actually, I believe just the reads need to be changed, I guess it's fine using pam_modutil_write()

Also, I am not a big fan of the fixed terminal string length as it is. Since we are using now the Unix 98 API, more specifically ptsname() that returns a string pointer to a static storage, better use just that and get rid of the TERMINAL_LEN and copying strings to a fixed len buffer.

Updated patch attached.

Comment 3 Tomas Mraz 2008-12-02 05:35:10 EST
Thanks, I'll post it upstream for another review.
Comment 12 errata-xmlrpc 2009-09-02 07:24:06 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.