Actually, I think sshd is changing the euid to the incoming user BEFORE
opening the PAM session. This makes more sense because a non-priveleged
user cannot change the # file descriptors above 1024, only root can.
Turning UsePrivilegeSeparation off makes sshd open the PAM session as
root, thus changing # file desc. before turning it over to the
non-privileged user.
Keep in mind this is just a best guess explanation. :-)
Cheers!
-Sean
On Mon, 2004-09-13 at 18:27, centos-admin@xxxxxxxxxxx wrote:
> Well, I found a workaround if not the answer. Modify
> /etc/ssh/sshd_config and set 'UsePrivilegeSeparation' to no, then
> restart sshd. The default for UsePrivilegeSeparation is yes.
>
> My guess is that, under UsePrivilegeSeparation yes, sshd is changing the
> euid to the incoming user AFTER opening the PAM session - thus causing
> the user to get the system defaults. Maybe somebody could provide a
> better explanation than me?
>
> Cheers!
> Sean
>
> On Mon, 2004-09-13 at 16:57, centos-admin@xxxxxxxxxxx wrote:
> > Why can't non-uid 0 users have more than 1024 file descriptors when
> > logging in via ssh?
> >
> > I'm trying to allow a user to have a hard limit of 8192 file
> > descriptors(system defaults to 1024) via the following setting in
> > /etc/security/limits.conf:
> > jdoe hard nofile 8192
> >
> > But when jdoe logs in via ssh and does 'ulimit -Hn' he gets '1024' as a
> > response. If he tries to set it with 'ulimit -Hn 8192' he gets an
> > 'Operation not permitted' error. If jdoe instead telnets to the box, he
> > gets the hard limit of 8192 file descriptors.
> >
> > Here is what happens when I set the hard limit to 512 in limits.conf:
> > jdoe hard nofile 512
> >
> > When jdoe logs in via ssh, he gets a hard limit of 512 file
> > descriptors. The same goes for telnet. So ssh is certainly reading the
> > limits.conf file and applying the settings, so long as nofile <= 1024.
> >
> > Why won't ssh allow users to have more than 1024 file descriptors???
> >
> > Many thanks!
> > -Sean
