|
HP OpenVMS Systemsask the wizard |
|
The Question is: I am trying to create a subprocess under some body elses account, using the sys$persona_create and sys$persona_assume and then a vfork()-execv() combination to start another executable. This other executable has read,write,execute permission to everybody, so, I would not expect the "Not owner" error code I get from execv(). This error message goes away IF I give the user thats being impersonated SYSPRV rights. So, my question is: if the executable is readable and executable by the world, why does the impersonated user need such high authority, and how can I solve this such that SYSPRV is no longer necessary? (Replacing the forkv()-execv() code with a lib$spawn also doesn't help; if the impersonated user doesn't have SYSPRV lib$spawn returns SS$_NOPRIV (=36).) Thanks The Answer is : You will want to use the lib$spawn or sys$creprc calls directly, as these provide far better diagnostics -- as you have clearly found. The OpenVMS Wizard prefers to avoid the fork operation, as sharing a virtual address space and sharing process control, contextual and related data structures is a particularly ugly implementation. To track the particular security check that triggers a protection error, please enable and use OpenVMS security alarms and/or OpenVMS security auditing. Mixing process ownerships within one job tree is hazardous and can and often does lead to various access failures related to resources shared among the subprocesses in the job tree -- the parent and subprocess communicate via mailboxes, and also share the job logical name table. The OpenVMS Wizard does not generally recommend configurations with mixed ownerships within a job tree. The persona settings deliberately do not survive an image rundown. The typical approach for creating a process under another username is the persona services and per-threads security, or the use of persona services and $creprc. If you want to use the per-threads security mechanisms that are available in OpenVMS V7.2 and later, please see the OpenVMS documentation set for details on threading, upcalls, and related topics. The vfork()-execv() sequence is not the equivilent of a process spawn operation (subprocess creation), it performs an image rundown and an an image startup. Please also see topics (4647) and (6099) for some details on mixing threading and asynchronous (AST) programming constructs, and please see topics (1661) and (2681) for details on programming errors and on requirements for shared memory operations.
|