Re: AXPVMS VMS731_UPDATE V2.0 glitch?

From: Wayne Sewell (wayne_at_tachysoft.com)
Date: 12/13/03 

Date: Sat, 13 Dec 2003 07:42:34 -0600

>Received: from MVB.SAIC.COM (198.151.12.104) by hardy.tachysoft.com (MX V5.3
> AnHm) with SMTP for <wayne@tachysoft.com>;
> Sat, 13 Dec 2003 05:08:20 -0600
>From: Paul Sture <nospam@sture.homeip.net>
>X-Newsgroups: comp.os.vms
>Subject: AXPVMS VMS731_UPDATE V2.0 glitch?
>Date: Sat, 13 Dec 2003 12:08:39 +0100
>Organization: Indexed, Prolog: 3, Using 4 keys
>Lines: 47
>Message-ID: <3FDB0147.246AAF24@sture.homeip.net>
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>X-Trace: news.uni-berlin.de 1071313725 2587675 80.254.165.138 ([132135])
>X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.3-1 Digital Personal
> WorkStation )
>Reply-To: Paul Sture <nospam@sture.homeip.net>
>X-Gateway-From: mvb.saic.com
>To: Info-VAX@Mvb.Saic.Com
>X-Gateway-Source-Info: USENET
>
>A heads up to those who have not applied this ECO yet.
>
>LOG_IO privilege is required to run WRITEBOOT, and the installation does
>not turn it on.
>
>-----------------------------------------------------------------------
>
>Execution phase starting ...
>
>The following product will be installed to destination:
> DEC AXPVMS VMS731_UPDATE V2.0 DISK$ALPHASYS:[VMS$COMMON.]
>
>Portion done: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%
>You lack LOG_IO privilege.
>%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
>%DCL-W-SKPDAT, image data (records not beginning with "$") ignored
> This kit includes a new APB.EXE file. The kit installation
> was not able to copy this file contiguously or to perform a
> writeboot. These operations must be done manually after the
> kit installation is complete. If this is not done your
> system may be unbootable.
>
>To copy the APB.EXE file contiguously, enter the command:
>
> COPY/CONTIGUOUS SYS$COMMON:[SYSEXE]APB.EXE SYS$COMMON:[SYSEXE]
>
>To perform a writeboot enter the command: MCR WRITEBOOT
>Update only the AXP portion of boot block. The AXP
>boot file is SYS$COMMON:[SYSEXE]APB.EXE
>
>...100%
>
>-----------------------------------------------------------------------
>
>This of course begs the question of whether turning all privileges on
>should be routine when performing PRODUCT INSTALL. I don't think I've
>ever needed to do that before.
>
>Or should it be considered a bug in this ECO?
>
>(In case anyone wonders why I didn't use the SYSTEM account, working in
>an environment with multiple system managers, we have developed the
>practice of using our own accounts for installations, for audit
>purposes.)

I don't think this is a good idea, unless the alternative accounts are fully
privileged as well. Product installation inherently requires privileges, and I
think *many* kits assume they are there. The old vmsinstal complained when not
running from the system account. Don't know if product install does or not
because I've never run it from another account.

If you *must* run from other accounts, they should have the same privileges as
system. That way you won't have problems like this.

If you don't want your regular account to have that much privilege, yet still
want this accountability thing, I would suggest creating new accounts for each
manager just for this purpose.

copy system mgr_paul/uic=[newuic]...

Seems like a cheap solution, unless you have a couple of thousand system
managers.

Wayne
===============================================================================
Wayne Sewell, Tachyon Software Consulting (281)812-0738 wayne@tachysoft.com
http://www.tachysoft.com/www/tachyon.html and wayne.html
===============================================================================
Randolph Duke (in Trading Places): "Mother always said you were greedy."
   Mortimer Duke: "She meant it as a compliment!"

Relevant Pages

  • Re: KB842773
    ... Please check if your account has the required privileges and enable what is ... This privilege identifies its holder ... As a background,> installation was launched from Admin account on a network and there is no> policies are implemented to deny pems to install hotfixes, tried as local> machine admin, tried to download and then install. ... we> need a fix ASAP due to a lot of people getting the same:> I receive this error when trying to download updated Windows Update> utility: ...
    (microsoft.public.windowsupdate)
  • AXPVMS VMS731_UPDATE V2.0 glitch?
    ... A heads up to those who have not applied this ECO yet. ... LOG_IO privilege is required to run WRITEBOOT, and the installation does ...
    (comp.os.vms)
  • Re: Preventing software installation in Admin account?
    ... admin account. ... What I want to do is to be able to enable "software installation prevention" ... It is important that administrators follow the rule of least privilege. ... The Importance of the Limited User Account. ...
    (microsoft.public.windowsxp.general)
  • Re: ASP.NET Impersonation / delegation
    ... If your security guys will not even allow delegation, ... Bruce - I think this is a major right to grant to the ASPNet account. ... I have included a description on SE_TCB_NAME privilege from one of the MS ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP.NET Impersonation / delegation
    ... there will not be any security risk? ... The MS documention does not recommend SE_TCB_NAME privilege to a any account other than the default LocalSystem. ... Processes that require this privilege should use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned. ... best alternative for impersonating an account that is specially created for ...
    (microsoft.public.win2000.developer)