rctl: root overriding resource limits?

ShelLuser

ShelLuser

Hi gang!

I compiled my first kernel today to add the RACCT and RCTL options in order to enable resource limits. Everything is working like a charm, but I did come across something peculiar.

The first thing I concentrated on is an IRC server which I'm using. It's executing while using the ircd user account and although it uses several modules it does not fork extra processes. As such it's an ideal situation to limit the maximum amount of processes (using maxproc) to 1.

Just to make sure I'm doing the right thing I verified my findings as follows:

Code: 
root@smtp2:/home/peter # ps aU ircd
PID TT  STAT    TIME COMMAND
863 v0- S    0:00.66 ircd: leiden.nl.eu.xxx.org (ircd)
root@smtp2:/home/peter # rctl -u user:ircd | grep proc
maxproc=1
So being confident about all this I added the following rule:
Code: 
user:ircd:maxproc:deny=1
which should limit the maximum amount of processes for the ircd user to 1.

To verify I changed the shell for the ircd user to /bin/sh and then tried this:

Code: 
root@smtp2:/home/peter # su - ircd
$ id
Cannot fork: Resource temporarily unavailable
$
At first I thought nothing of it. After all; I've limited the ircd user, and as you can see here it can indeed only use one process, in this case that is the shell itself.

But if I then move to another console and check the currently used resources again using rctl I now get to see this:

Code: 
root@smtp2:/etc # ps aU ircd
 PID TT  STAT    TIME COMMAND
 863 v0- S    0:00.72 ircd: leiden.nl.eu.xxx.org (ircd)
5999  5  I+   0:00.01 -su (sh)
root@smtp2:/etc # rctl -u user:ircd | grep proc
maxproc=2
root@smtp2:/etc # rctl
user:ircd:maxproc:deny=1
That doesn't look quite right.

At first I thought that every instance (process?) which the ircd user starts gets limited, but the rctl output makes me believe that I've actually managed to override the limitation somehow.

In the mean time I've also tried setting a password for ircd, and if I then try to use $ su ircd or $ su - ircd while using my regular account it also works. I can even login on the system console as well. Even though the ircd user already had two processes running at that time.

Does anyone have an idea as to what is going on here? I would have expected that the moment I tried to start a new shell for ircd the system simply would deny to start it.
 
I think I solved it, though I'm still investigating.

In the mean time I started reading up on limiting users which is normally done using the /etc/login.conf file. Here you can define login classes and their limits, then assign users to such a login class using chpass (or several other utilities which allow you to control /etc/master.passwd).

This also works using so called resource limits. The limits which you can set using rctl(8) are exactly the same as those defined in login.conf(5).

Now here's the thing. When reading the handbook chapter mentioned above I came across this:

Resource limits differ from the default login capabilities in two ways. First, for every limit, there is a soft (current) and hard limit. A soft limit may be adjusted by the user or application, but may not be set higher than the hard limit. The hard limit may be lowered by the user, but can only be raised by the superuser. Second, most resource limits apply per process to a specific user, not to the user as a whole. These differences are mandated by the specific handling of the limits, not by the implementation of the login capability framework.
Click to expand...
I think this fully applies to the situation in my previous message.

Of course in my opinion this section should have been mentioned (either quoted or at least referenced) in the chapter about resource limits as well.

But that's where the Problem Reports come in.

PS: FreeBSD is awesome! This totally brings back the good times when I was using Solaris which provided ppriv which could also limit certain privileges ('resources').
 
You must log in or register to reply here.
Back
Top