Re: [vserver] Number of open files inside VServer doesn't work

Thorsten Büker wrote:
> Hi together,
>
> aroused by its reconfiguration (integration of Opcode APC) an Apache,
> running inside a VServer, suffers from to many open files:
>
> Apr 30 15:40:49 hostname kernel: grsec: From 134.130.85.167: denied
> resource overstep by requesting 1024 for RLIMIT_NOFILE against limit
> 1024 for /vservers/web/usr/bin/php4-cgi[php4-cgi:23500]
> uid/euid:1111/1111 gid/egid:1111/1111, parent
> /vservers/web/usr/sbin/apache2[apache2:2773] uid/euid:0/33 gid/egid:33/33
>
> Raising the permitted number of open files by the following steps didn't
> work as I expected. Beside adding the bcapability SYS_RESOURCE in the
> VServer's configuration I amended the subsequent lines to the Vserver's
> /etc/security/limits.conf (with vhost-user representing the uid 1111
> from above):
>
> root soft nofile 1536
> root hard nofile 1536
> vhost-user soft nofile 1536
> vhost-user hard nofile 1536
> www-data soft nofile 1536
> www-data hard nofile 1536

You don't really want to give the guest CAP_SYS_RESOURCE... If you haven't
limited the guest already in /etc/vservers/<guest>/ulimits/nofile*, pam
should be able to set those limits (with recent utils).

> Entering the VServer's context by "vserver web enter" and asking for
> information by "ulimit -a" for root still returns:
>
> [...]
> open files (-n) 1024
> [...]

As expected, it's not using pam. See above.

> Proceeding to user www-data or vhost-user delivers the expected results:
>
> web:/etc/security# su www-data -c "ulimit -a"
> [...]
> open files (-n) 1536
> [...]

... since this does use pam.

> Increasing the permitted number of open files for root on the hostsystem
> outside the VServer's context leads to a higher number inside the
> Vserver, too. But as there's no user with uid 1111 on the hostsystem, so
> this approach doesn't help.

Doesn't matter. pam on the host has nothing to do with it, _if_ you
configure your guest correctly. The fact that you inherit root's ulimit on
the host is simply because you didn't tell the utils to do anything, so
they don't.

> The kernel configuration of VServer 2.6.22.16-grsec2.1.11-vs2.2.0.6,
> used in combination with backported util-vserver 0.30.210-8bpo2, looks
> as follows:

Upgrade your utils, and your kernel. Both are known to be problematic.

> CONFIG_VSERVER_LEGACY=y
> # CONFIG_VSERVER_LEGACY_VERSION is not set
> CONFIG_VSERVER_DYNAMIC_IDS=y
> CONFIG_VSERVER_LEGACYNET=y
> # CONFIG_VSERVER_REMAP_SADDR is not set
> CONFIG_VSERVER_COWBL=y
> # CONFIG_VSERVER_VTIME is not set
> CONFIG_VSERVER_PROC_SECURE=y
> # CONFIG_VSERVER_HARDCPU is not set
> # CONFIG_TAGGING_NONE is not set
> # CONFIG_TAGGING_UID16 is not set
> # CONFIG_TAGGING_GID16 is not set
> CONFIG_TAGGING_ID24=y
> # CONFIG_TAGGING_INTERN is not set
> # CONFIG_TAG_NFSD is not set
> # CONFIG_PROPAGATE is not set
> CONFIG_VSERVER_PRIVACY=y
> CONFIG_VSERVER_CONTEXTS=256
> CONFIG_VSERVER_WARN=y
> CONFIG_VSERVER_DEBUG=y
> CONFIG_VSERVER_HISTORY=y
> CONFIG_VSERVER_HISTORY_SIZE=64
> # CONFIG_VSERVER_MONITOR is not set
> CONFIG_VSERVER=y
>
>
> Is there any clue I'm missing? Any hints appreciated, thanks!
>
> kind regards,
> Thorsten
>

-- 
Daniel Hokka Zakrisson