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.
[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?
I guess I'm wondering about limits on the pwd->pw_uid user interfering
with the activities of other modules in the stack.]
Cheers
Andrew
PS. Since you did your commit, I've been unable to checkout the pam
sources from sourceforge..
http://sourceforge.net/support/?func=detailsupport&support_id=109094&group_id=1
