[Info-vax] Integrity Privilege Difference

[Richard Maher]

Richard Maher wrote:
> Maybe it's exiting the routine before setting the privilege. If it's a UWSS
> then presumably it vets the input parameters before working with them?
>
> Try returning with ss$_abort (or something identifiable so you don't have to
> worry about using a debugger) and just move it down dow down the code.
>
> Worth ruling out a parameter/address/type change between IA64/Alpha before
> looking for anything else.
>
> Cheers Richard Maher
>
>
>
> "Williams, Arlen" <arlen.williams at hp.com> wrote in message
> news:mailman.4.1313074090.3397.info-vax_rbnsn.com at rbnsn.com...
> It is an installed image of a user written system service written in C.
>
> -----Original Message-----
> From: info-vax-bounces at rbnsn.com [mailto:info-vax-bounces at rbnsn.com] On
> Behalf Of Hein RMS van den Heuvel
> Sent: Wednesday, August 10, 2011 12:48 PM
> To: info-vax at rbnsn.com
> Subject: Re: [Info-vax] Integrity Privilege Difference
>
> On Aug 10, 10:23 am, "Williams, Arlen" <arlen.willi... at hp.com> wrote:
> > I am migrating some code from Alpha to Integrity and have run into a
> > difference. > At some point in the code it goes into EXEC mode and adds a
> > privilege to the current privileges. On the Alpha, when it goes back in
> > USER mode, the added privilege is still there.
>
> In the same image activation? Or a next image.
> Are installed images in play here?
>
> > But on Integrity, the added privilege is no longer there.
>
> Where you able to positively verify that the privs were there 'for a
> while'?
>
> > Is this the way it is supposed to be working?
>
> Noop.
>
> > Is this a change that I can find in documentation somewhere? Is there a
> > way to keep this functionality the same?
>
> Gotta think it is a programming issue, bad data structure or some
> such.
>
> I have a tiny tool to grab other privs, once granted CMEXEC.
> Works fine for me, an Alpha and Itanium alike.
> That example leaves the privs set as requested by 'prmflg=1
> ( $ help sys $setprv arg )
>
> fwiw,
> Hein
>
> #include descrip
> #include prvdef
> #include stdio
> #include string
> typedef struct { short len, cod; void *address; int *retlen; } item;
> typedef struct { long count; void *address; } desc;
> int     sys$setprv(), sys$cmexec();
> main(int argc, char *argv[]) {
>     __int64 privs_step_1 = PRV$M_CMEXEC ;
>     __int64 privs_step_2 = PRV$M_SYSGBL | PRV$M_SYSNAM | PRV$M_SYSLCK;
>     int     setprv_args[]  = { 4, 1, (int) &privs_step_2, 1, 0 };
>     int     status, i;
>     status = sys$setprv ( 1, &privs_step_1, 0, 0);
>     if (status & 1) {
>        status = sys$cmexec (&sys$setprv, setprv_args);
>     } else {
>         printf ("Sorry... could not get required CMEXEC, privs.\n");
>     }
> return status;
> }
>
>

Hasten to add WRT - "Is this the way it is supposed to be working? ":
-

*YES*! AbsoTMESISluteley!

For a UWSS to return to User-Mode (a.n.other caller's mode) in a state
of elevated privilege would be a catostrophic failue!

Perhaps, on the Alpha, the mainline/calling image was also installed
with privs?

Cheers Richard Maher