OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: PAM and system limits
From: Andrew Morgan (morgantransmeta.com)
Date: Thu Nov 30 2000 - 17:28:28 CST

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

_______________________________________________
Pam-list mailing list
Pam-listredhat.com
https://listman.redhat.com/mailman/listinfo/pam-list