No.  Pags are maintained by the kernel and if "x" has been given out it
will not be given out again (unless we wrap around but that, while it
needs to be addressed at some point, is not terribly likely to be a
problem for now. )

Peter


On Wed, 13 May 1998, J.A. Harkes wrote:

> 
> "Peter J. Braam" wrote:
> > - any process can execute newpag and thereby leave an
> > authentication group of which is was a member
> 
> This fact combined with the `simple' incremental pag-allocation in your
> patch creates the possibility for malicious users to `impersonate'
> another user.
> 
> Let's say I know a user P has pag #x, It is trivial to implement:
> 
>    while (getpag() != x) newpag();
>    exec('/bin/sh' something)
> 
> And presto, an authenticated shell.
> 
> But I still think the idea is good. Although it's a bit silly to attempt
> to clip the wings of `root'. That's where the capability stuff should
> kick in, not a single root user anymore, just a horde of `capable'
> users.
> 
> I've just been looking at what SGI IRIX provides, and found a set of
> process-accounting related functions which use an (almost) equivalent
> interface:
> 
> Small excerpt from array_sessions(5)
> 
>     An array session is a group of processes all related to each other
>     by a single unique identifier, the  array session handle. The
>     processes don't necessarily have to belong to the same parent-child
>     chain, and don't even have to be running on the same system.
>     However, the default is for a child process to inherit the array
>     session handle of its parent, so in the average case the processes
>     in an array session are parents/siblings/children of each other and
>     reside on the same system. An array session is considered to be
>     active from the time it is first created until the last process that
>     is a member of it exits.
> 
>     The goal of an array session is to correlate all the processes that
>     belong conceptually to the same login session or batch job, even if
>     those processes are running on several separate machines in an
>     array.  Then, with the help of external software, the array session
>     can potentially be treated as a single unit for the purposes of
>     accounting, checkpoint/restart, job control, etc.
> 
> syscalls: newarraysess(2), setash(2), getash(2)
> 
> This is however SGI specific and non POSIX/XOPEN. Isn't there some POSIX
> equivalent?
> 
> Jan
>