Bug 111175 - PAM /etc/security/limits.conf permissions issue
PAM /etc/security/limits.conf permissions issue
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
:
: 113559 (view as bug list)
Depends On: 115442
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-28 13:46 EST by Nick Lamb
Modified: 2007-11-30 17:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-11 05:01:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nick Lamb 2003-11-28 13:46:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031030

Description of problem:
Either the /etc/security/limits.conf file has incorrect permissions
set by the RPM installation, or the associated PAM module is broken,
as far as I can tell.

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

How reproducible:
Always

Steps to Reproduce:
1. Try to ssh to localhost on default Fedora Core installation
This fails, logging fatal: PAM session setup failed[6]: Permission
denied to /var/log/secure

2. Change permission on /etc/security/limits.conf to -rw-------
This removes read privilegs for everyone but root

3. Now you can connect to localhost using ssh

4. Put back permissions on /etc/security/limits.conf

5. Back to square one, can't ssh to localhost

Additional info:

This may be a documentation/ permissions bugs for the PAM package, or
it might be a symptom of something more serious. Labelling as a
security issue until someone examines it and figures out what is
actually wrong.
Comment 1 Miloslav Trmac 2003-11-28 14:33:02 EST
Works fine here, FWIW.
Comment 2 Need Real Name 2004-03-02 05:22:08 EST
The problem is not present in the standard Fedora Core 1 installation.

I can reproduce the problem if I change something in
/etc/security/limits.conf

By adding the following lines to limits.conf:

*               soft    nofile  2048
*               hard    nofile  4096

And then trying to login from a remote PC (as a regular user, not
root), the problem appears in /var/log/messages:

sshd[2161]: fatal: PAM session setup failed[6]: Permission denied

The problem disappears as soon at the permissions are set to:
-rw-------

My version of pam is 0.77-15.
Comment 3 Josh Bressers 2004-06-18 17:03:22 EDT
Removing security severity; This is a bug, not a security issue.
Comment 4 Jan Knutar 2004-06-28 03:22:57 EDT
This bug seems to exist in Fedora Core 2 as well.

If I modify /etc/security/limits.conf, the same message as above will 
appear from sshd, about pam:
PAM session setup failed[6]: Permission denied

If I chmod go-r /etc/security/limits.conf, the message in 
/var/log/secure goes away, but is replaced by a:

pam_limits[16469]: can not read settings from /etc/security/limits.
conf
polaris pam_limits[16469]: error parsing the configuration file

I don't think it's a syntax error on my part in limits.conf, since I 
get the same error message with all of the file being comments. So 
the work around suggested actually disables limits.conf.


What I am trying to achieve:
Per user custom limits, such as higher number of open file 
descriptors for certain users.

What I do:
Edit /etc/security/limits.conf and add the lines
user hard nofile 16384
user soft nofile 8192

What happens:
Unable to log in through sshd with that username anymore, error 
message: fatal: PAM session setup failed[6]: Permission denied


This on Fedora Core 2, tested on Fedora Core 1 with the same results.
Comment 5 Dennis Wagelaar 2004-07-19 04:44:51 EDT
The problem seems to occur only when trying to *raise* the limits for
SSH sessions. See also bug #115442, where a workaround is proposed for
sshd.

Addition to that: one could create a "/etc/sysconfig/sshd" file,
containing "ulimit -n 16384" or something similar..
Comment 6 Sergio Monteiro Basto 2004-08-06 12:55:21 EDT
Same here with FC1 - pam-0.77-15
appear from sshd, about pam:
PAM session setup failed[6]: Permission denied

I read this 
http://list.linux-vserver.org/archive/vserver/msg06663.html
and applied :
comment out pam_limits.so from both /etc/pam.d/sshd and
/etc/pam.d/system-auth. 
seems work better 
Comment 7 B.R. 2004-09-02 01:01:30 EDT
I've verified this problem persists in Fedora Core 2.

openssh-3.6.1p2-34
pam-0.77-40

Also, I run SSH via xinetd.

xinetd-2.3.13-2

Typically I include a 'nice' value in the xinetd configuration for
ssh.  When this value is included, any non-root ssh connection is
immediately terminated after authentication and the following error
message is added to the /var/log/secure file.

sshd[1530]: fatal: PAM session setup failed[6]: Permission denied

Removing the 'nice' value from the xinetd configuration file allows me
a successful non-root login.  Bummer ... what other services does this
'limits' glitch affect ...
Comment 8 Tomas Mraz 2004-09-09 07:22:41 EDT
OK it seems to me that there are mixed together many different bug
reports here.

On FC 2 and latest devel I see only the bug as reported in the
comments #6 and #7.
Comment 9 Christian Ashby 2004-09-20 14:10:47 EDT
I confirm that this exists still in FC2.

To summarise in simpler all-in-one-commment terms:
- Clean install of FC2
- Add limits to /etc/security/limits.conf
- Restart SSHD
- SSH login fails with following error:
    fatal: PAM session setup failed[6]: Permission denied
- chmod /etc/security/limits.conf to -rw------
- SSH login works fine.

Hope this helps. It'll only be noticable to someone who's tweaked 
their limits (I did so to get Oracle 10g to work)
Comment 10 Tomas Mraz 2004-09-21 02:47:41 EDT
Please try latest development packages of openssh and pam.

If you chmod the limits file as you write you will effectively disable
it's processing and so it won't fail.
Comment 11 Jindrich Novy 2004-09-21 09:56:24 EDT
*** Bug 113559 has been marked as a duplicate of this bug. ***
Comment 12 Wayne Johnson 2004-10-08 14:02:49 EDT
I've run into this problem with FC2 at the latest release level.

It seems that I increased some of the limits in limits.conf.  Now, if 
I attempt to login as other than root, the session gets killed.  Now 
the interesting part, if I restart sshd, it works fine.

I hypothesize that the new feature in sshd that causes new sessions 
to be run as the user instead of root, is having trouble initiating a 
new instance because the new instance uses larger limits that what 
the original process does.  When you restart the parent sshd process, 
it picks up the enlarged limits and everything works fine.

Comment 13 Tomas Mraz 2004-10-11 05:01:43 EDT
Yes, it's exactly the way you write. But there is nothing we can do
with that (at least on the pam side).

Comment 14 Need Real Name 2004-10-12 13:35:01 EDT
Interesting.. I am seeing this problem on a system I just upgraded
from FC1 (with all "official" updates applied, and it worked fine) to FC2.

On FC2, I can ssh in fine (as a non-root user, and with a modified
limits.conf) IF I use the original FC2 kernel: kernel-2.6.5-1.358.

However, if I boot into the latest currently available FC2 kernel:
kernel-2.6.8-1.521

it fails as you all describe above, with the PAM error.

Anyone have any comments as to why this would succeed on the older
kernel, and fail on the newer kernel?

Can anyone else see if he gets the same difference in behavior?
Comment 15 Need Real Name 2004-10-12 14:51:36 EDT
More information....

for me, the line in limits.conf that was killing my SSH logins was the
following:

*              hard    memlock         131072

I did a little testing and here is what was happening.

If I logged in on the console, my Hlim (hard limit) would get set to
131072, and my Slim (soft limit) would get set to 32.

However, if I try to SSH to the system, the Hlim apparently gets
knocked back down to my Slim (so they're both at 32 at this point). 
Then, per the above setting, it would apparently try (as my
unprivileged userid) to increase the hard limit back to 131072; and as
we all know, a regular user cannot increase his own Hard limit, he can
only increase the Soft limit (up to the Hard limit).

How do I know this?  Because if I set the Hlim to 32 in limits.conf, I
can log in via SSH without any problems.  Then, if I do 'ulimit -Ha'
in my SSH session, it tells me the hard limit is set to 32 (same as my
prior and current Soft limit).

So, now the question is: is this an issue with SSHD, or with the
kernel?  Why does this only occur with the newer kernel, and not with
the older?  What is responsible for knocking down my Hard Limit (this
should never occur throughout this process AFAICT, and IMHO is the
cause of the whole problem).
Comment 16 Sergio Monteiro Basto 2004-10-25 14:09:06 EDT
who change the bug for "not a bug" 
is one of the biggest bug on fedora ...

only my solution on #c6 can resolv the situation ignoring limits 
Comment 17 brian duke 2004-11-23 00:23:36 EST
I can confirm this is still out in the wild.
FC-2 can either be fixed via #c6
or in /etc/ssh/sshd_config changing 

#UsePrivilegeSeparation yes

into 

UsePrivilegeSeparation no

this works too but I don't think either is the best plan.
Comment 18 B.R. 2005-02-22 04:17:35 EST
I just tested this again.  I am running openssh via xinetd with a
"nice" value.  (I posted the bugzilla entry <a
href="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111175#c7">#7</a>.)
 Specifically: <br>
kernel-2.6.10-1.766_FC3<br>
openssh-server-3.9p1-7<br>
pam-0.77-66.2<br>
xinetd-2.3.13-4<br>
With these updates, this issue appears to have disappeared.  I am not
using privilege separation in sshd_config and I'm not making
limits.conf unreadable.  Whereas I believe listing the "resolution" as
NOTABUG is a bit misleading, I do think the "status" of CLOSED is
appropriate -- at least for FC3.
Comment 19 Tomas Mraz 2005-02-22 04:25:31 EST
This is not a bug in PAM, it's a bug in openssh privsep mode how it
calls pam (with dropped privileges). This is fixed in openssh >= 3.8p1.

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