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... :*(
Cheers
Andrew
