[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM and system limits

On Thu, 30 Nov 2000, Andrew Morgan wrote:

> Jan Rekorajski wrote:
> > > One question. Is there any reason why you can't change the euid back
> > > again afterwards? This seems more transparent to me. (Some code actually
> > > has the real uid set to something other than the effective one while
> > > authenticating anyway).
> > 
> > I'm not changing euid. I'm changing only real uid, and no, can't switch
> > back, because limits are compared agains current real uid.
> Sorry, I meant the uid. In general, its the responsibility of the
> application to handle the setting of uids, modules need to be
> transparent wrt to this - some modules actually depend on the uid value
> to determine who originated the request.
> Why can't you do this?:
>    {
>       uid_t old_uid = getuid();
>       setreuid(pwd->pw_uid, -1);
>       retval = setup_limits(pwd->pw_name, ctrl);
>       setreuid(old_uid, -1);
>    }

Because in do_fork() in kernel, the RLIMIT_NPROC is checked against number
of processes owned by current process owner (real uid). So if you do as root:

setrlimit(NPROC, n)
fork() <- this will fail because root may have more than n processes
	   not the user

but if you do
setreuid(pwd->pw_uid, -1);
setrlimit(NPROC, n)
- if you go back to saved uid here we will be back at previous situation
fork() <- this will fail only if the user have more than n processes

And real uid at this stage is not that important as in auth or account,
and changing all apps is OMHO a RPITA.

> > > Please file a bug report and then apply your change (with a change to
> Didn't see the CHANGELOG checkin.


Jan Rękorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
BOFH, type MANIAC         |                   -- TROOPS by Kevin Rubio

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []