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

Re: PAM and system limits

Jan Rekorajski wrote:
> 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).

> > 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:

So, you are saying that the limit isn't actually enforced until after
login (say) has already fork()d a shell? I see.

Well, in that case, I would like to see the second setreuid() call
there, but conditionalized on some sort of module argument. I believe
strongly, that changing the behavior of the module will actually break
some app or stack of modules, and I'd like admins to be able to fix this
without a recompile.

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

Sorry, these acronyms are beyond me... :*(



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