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
> > > CHANGELOG).
>
> Didn't see the CHANGELOG checkin.
Done.
Jan
--
Jan Rękorajski | ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, type MANIAC | -- TROOPS by Kevin Rubio
