On Fri, 01 Dec 2000, Andrew Morgan wrote:
> Jan Rekorajski wrote:
> > > > > 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:
>
> > Will it be ok If I add a module argument "change_uid" and wrap the setreuid()
> > call which is already there around it? It will be compatible,
> > and only if somebody adds it module will do setreuid().
> > This way we can add an information saying:
> > "If you have problem with limits - like login not forking a shell for
> > a user who has no processes then add the change_uid option. Be warned that
> > something else may break when you do this"
>
> OK, that is at least backwardly compatible.
I'll fill in bug report and do commits when sourcefge WWW stuff
will be back online.
> [Although, I'm still not clear on what is incorrect about having two
> calls to setreuid as in the case above. Doesn't it do the counting
> correctly for pwd->pw_uid but make things more transparent for the stack
> of modules?
This is due to the way kernel keeps track of current owner of the process.
> PS. Since you did your commit, I've been unable to checkout the pam
> sources from sourceforge..
Hmm, really strange. No problems here.
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
