Bug 473970 - pam_filter does not work in Red Hat EL5
pam_filter does not work in Red Hat EL5
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam (Show other bugs)
5.2
All Linux
high Severity high
: rc
: ---
Assigned To: Tomas Mraz
BaseOS QE
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2009-09-02 07:24:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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):

pam-0.99.6.2-3.27.el5

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
[SOMEUSER@RHEL5 ROOT]$ LS
LS: .: pERMISSION DENIED

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

Hi,

(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;
     17 
     18        while (count > 0) {
     19                block = read(fd, &buffer[offset], count);
     20 
     21                if (block < 0) {
     22                        if (errno == EINTR) continue;
     23                        return block;
     24                }
     25                if (block == 0) return offset;
     26 
     27                offset += block;
     28                count -= block;
     29        }
     30 
     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.

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

http://rhn.redhat.com/errata/RHBA-2009-1358.html

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