[Info-vax] Job logicals linked to a process

[Chris Townley]

On 09/01/2021 01:15, Chris Townley wrote:
> On 09/01/2021 00:54, Stephen Hoffman wrote:
>> On 2021-01-09 00:11:22 +0000, Chris Townley said:
>>
>>> All in the past,
>>
>> Yet you're here, asking this, which implies this mess is seemingly 
>> rather less in the past than might be preferred.
>>
>>> ...but we only allowed shared usernames in either totally read only , 
>>> or with updates authenticated and logged by other means.
>>> The former had no password, and the second password was well known, 
>>> but without tyhe secondary credentials was read only. Worked for years!
>>>
>>> Sadly now all in the past
>>
>> Not the first time I've heard folks ask for logins to manage logins, 
>> and not the first time—as has been done here—folks have implementing 
>> per-user logins to manage shared logins.
>>
>> Privileges to control privileges was another similarly classic 
>> request. Fun fact: there's a means to grant a user SETPRV privilege, 
>> but where that privilege is entirely unavailable for committing 
>> mayhem. But I digress.
>>
>> Generally, it's either best to either fix the shared login problem 
>> with per-user logins issued, or to do what management seemingly wants 
>> done here and ignore it.
>>
>> Which means you'll prolly end up adding your own login mechanism into 
>> SYLOGIN or the user's LOGIN, and preferably with the shared user 
>> marked as CAPTIVE or RESTRICTED or it'll get bypassed. Create your own 
>> login.
>>
>> It's been interesting watching how fast some these cases can get fixed 
>> when management decides, too—more than a few of these cases go from 
>> "impossible" or "never" or "infeasible" or "unaffordable" to "done", 
>> once the issue is re-decided.
>>
>> But in other cases, management was somewhere between oblivious or 
>> overloaded or otherwise overwhelmed, and some management seemingly 
>> enjoyed keeping IT staff into intractable and untenable situations. 
>> Been there. Not Fun.
>>
> Totally not relevant now. The system was decommissioned in 2013, and the 
> company went into administration last May, and is now moribund.
> 
> Actually the solution was forced onto me by management,and I didn't 
> disagree with the reasoning. We already had a pretty good secondary 
> login, by clock number for our RDT users on FLT, or later with HHTs. I 
> simply extended this onto the captive generic accounts so that any 
> access for more than read only required secondary authorisation (note no 
> Z over here!)
> 
> It worked well, and avoided the productivity loss of multiple warehouse 
> users logging an out just to enter one document or whatever.
> 
> I would probably not do it again, but back in the early noughties many 
> non technical users struggled to get a password in within the timeout.
> 
> My only reason for asking was out of interest, as many years ago I could 
> have used it. I did reset the process name to include the clock number, 
> but that didn't always work.
> 
> Chris
> 

And as for privilege, although all users were captive, I reduced privs 
significantly. I inherited, and improved a mechanism to use an installed 
image to run any of the few command/programs that required elevated 
priv. I was the only user that had SETPRV.

Chris