New post
Article
John Murray · Mar 6, 2016 2m read

Who does Windows think I am?

#Caché #Terminal #Ensemble #Callout #Microsoft Windows

When my COS code is executing in a Caché process it might want to interact with the host operating system. For the purpose of this post I'm focusing on a Windows host, but much of it applies to other host OS platforms as well.

A common example of host OS interaction is when my process wants to read from or write to a file. What credentials will apply when Windows is checking whether or not to allow me access to the file?

To answer that we need to consider another question. How did our process start?

If we're in an interactive terminal session, perhaps we launched this from the Caché cube on the server's desktop. In such a case we will already have authenticated to Windows to get onto the server's desktop, so our Caché process can run with those Windows credentials.

Or our interactive terminal session might be a telnet one, where we're using a telnet client app such as Caché Telnet. The telnet client communicates with the Caché server's telnet service over TCP/IP. The server has no idea what Windows credentials you're running the telnet client with. Indeed, you might not be running the telnet client on Windows at all. So your Caché server process runs under the same Windows account as the Caché instance started up with. Caché runs as a Windows service, and part of a service definition is what account the service should "log on as".

When Caché is installed using the Minimal security option, its service is set up to run under the Local System account of Windows. While this may be adequate, one key limitation is that this account can never access Windows networking fileshares, e.g. \\FileServer\Team\ProjectSpec.xml.

So if your code works when run from a terminal session on the server, but fails when run from a telnet session, or from a Studio add-in, or from a web application, you might be running up against the issue of "Who does Windows think I am?".

UPDATE: Starting at 2015.2 (I think), it is important to use the cinstall.exe utility (located in your installation's bin subdirectory) to change which account the service runs as:

cinstall setserviceusername <InstanceName> <username> <password>

If you don't do this but instead only  change the setting in the Log On tab of the Windows service, then in certain circumstances the $ZF() functions may return a -1 failure code. See http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCNV_C147006 for more details.

3
0 885
Discussion (6)2
Log in or sign up to continue
Eduard Lebedyuk · Mar 7, 2016

Is there any way to set environmental variables before calling $zf?

For example I want to add something to PATH, but if I do it in an actual $zf call it would be a lot longer and hard to read. So is there any way to set environmental variables for current process from Cache?

1 0
John Murray · Mar 7, 2016

Interesting question. I expect you're already aware of how we can get the value of an environmental variable thanks to the GetEnviron method of %SYSTEM.Util

USER>w $system.Util.GetEnviron("TEMP")
C:\WINDOWS\TEMP
USER>

Maybe someone else knows how you can amend one. But if it's not possible, can you improve readability in your code by concatenating the components of your $ZF argument in several stages into a local variable, then passing that variable as the argument to $ZF ?

1 0
Timothy Leavitt · Mar 7, 2016

For what it's worth, a more direct answer to the question "Who does Windows think I am?" can be found programmatically with:

$System.Process.UserName()

(2015.1+; see class reference)

2 0
Bill McCormick · Mar 7, 2016

FYI - there are some changes coming here in 16.2

 

I posted a compatibility blog statement that has not been approved yet but there are a few changes coming in this area.

0 0