Re: System UICs

Liste des GroupesRevenir à co vms 
Sujet : Re: System UICs
De : craigberry (at) *nospam* nospam.mac.com (Craig A. Berry)
Groupes : comp.os.vms
Date : 08. Jun 2024, 17:29:22
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v420t2$2m8ap$1@dont-email.me>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
On 6/7/24 8:55 PM, Jim Duff wrote:
On 8/6/24 10:26, Lawrence D'Oliveiro wrote:
On Fri, 7 Jun 2024 20:11:13 -0400, Arne Vajhøj wrote:
>
VMS allows multiple usernames with same UIC, but it practically
never happens.
>
The point being that privilege separation is done based on UIC, not
username.
 And VMS does it by username.  Some UICs on VMS are defined to be in the system group.  Some UIDs on unix are defined to be in the system group. So what?
 
For example, on *nix, a daemon might start out as root and then
call setuid(2) and friends to isolate the current process as a
nonprivileged user. The UID to use can be easily obtained by looking up a
symbolic username in the /etc/passwd file. How would you do this on VMS?
 How do you change username (and granted identifiers and/or UIC) on VMS?
 $assume_persona system service and co.  You'll find they're a little more flexible than setuid.  Example here:
 https://www.eight-cubed.com/examples/framework.php?file=sys_persona.c
 Or did you mean "how would you look up a UIC by username?  From DCL, f$identifier lexical:
 $ uic = f$identifier ("SYSTEM", "NAME_TO_NUMBER")
$ write sys$output f$fao ("!%U", uic)
[1,4]
$
  From an executable, $getuai system service.
 On VMS, to start something with privileges and permanently drop them after initialization and *guarantee* that the process can never get them back (unlike both setuid and the persona system services, which can both resume their "natural" id):
 Set up a user with authorized privs of (for example) NETMBX, TMPMBX, and default privs of SYSPRV, NETMBX, TMPMBX.
 When the process starts, it will have SYSPRV, but after dropping the privilege (set proc/priv=nosysprv in DCL, $setprv system service in a program), you cannot re-enable it.  Use a captive (or restricted) command procedure (or run a program without a command interpreter) to ensure the process cannot retain or regain privs.
Depending on what the real question was, you might also end up calling
sys$create_user_profile to get the rights and privileges of the current
process.

Date Sujet#  Auteur
7 Jun 24 * System UICs21Lawrence D'Oliveiro
7 Jun 24 `* Re: System UICs20Hans Bachner
7 Jun 24  +- Re: System UICs1Lawrence D'Oliveiro
7 Jun 24  `* Re: System UICs18Lawrence D'Oliveiro
7 Jun 24   `* Re: System UICs17Arne Vajhøj
8 Jun 24    `* Re: System UICs16Lawrence D'Oliveiro
8 Jun 24     `* Re: System UICs15Arne Vajhøj
8 Jun 24      `* Re: System UICs14Lawrence D'Oliveiro
8 Jun 24       +* Re: System UICs10Arne Vajhøj
10 Jun 24       i`* Re: System UICs9Stephen Hoffman
10 Jun 24       i +* Re: System UICs4Rich Alderson
11 Jun 24       i i`* Re: System UICs3Lawrence D'Oliveiro
12 Jun 24       i i `* Re: System UICs2Rich Alderson
12 Jun 24       i i  `- Re: System UICs1Lawrence D'Oliveiro
11 Jun 24       i `* Re: System UICs4Lawrence D'Oliveiro
12 Jun 24       i  `* Re: System UICs3Rich Alderson
12 Jun 24       i   `* Re: System UICs2Lawrence D'Oliveiro
12 Jun 24       i    `- Re: System UICs1Rich Alderson
8 Jun 24       `* Re: System UICs3Jim Duff
8 Jun 24        +- Re: System UICs1Lawrence D'Oliveiro
8 Jun 24        `- Re: System UICs1Craig A. Berry

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal