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)
Why did you change the pam_modutil_read/write to regular read/write? Is it really necessary?
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.
Thanks, I'll post it upstream for another review.
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