Managing the LOCKDOWN allowlist: find out what paths are included, and add paths where necessary
SAS Viya compute, connect and batch servers (collectively called SAS Viya Platform programming run-time servers) have a feature called LOCKDOWN, which does two things.
It limits access to SAS language features which could be security concerns at many sites, by default preventing user-written SAS code from using them unless a SAS Administrator enables those language features.
And it limits filesystem access in user-written SAS code statements to paths in a lockdown allowlist and their subdirectories.
In this post, we'll see how to find out what paths are in the lockdown allowlist in your SAS Viya deployment. We'll see how to add paths to the list; easy for a SAS Administrator but (you may be relieved to know) not possible for non-administrator users.
We will also see how filesystem paths for additional volumes you mount to the programming run-time pods are automatically added to the lockdown allowlist, removing the need for administrators to do that.
See paths in the lockdown allowlist
The SAS programming language LOCKDOWN statement has a list argument that, as described in its documentation, prints the current valid paths in the lockdown path list to the SAS log. This list is an optimized path list. Subdirectories and duplicate pathnames are not shown. The syntax is simply:
lockdown list;
However once a SAS compute, connect or batch session has entered the locked-down state towards the end of its initialization process, further lockdown statements are not executed.
You can try it yourself. If you run the above lockdown list; command in a SAS Studio program tab, then irrespective of whether you are a SAS Administrator or not, the resulting log output will include a warning like this:
WARNING: The LOCKDOWN statement was not executed. Set the LOCKDOWN system option and add the LOCKDOWN statement to an AUTOEXEC file
or to the INITSTMT statement.
So a SAS Administrator must put lockdown statements (including the one above) in either:
- an autoexec code block for a compute context, so they run only for compute sessions started under that compute context, or
- in the autoexec code block for the compute server, so they run for all compute sessions.
However, log output from the execution of SAS code statements in either of those autoexec code blocks do not appear in the log output that is visible to the user in SAS Studio. But they are written to the compute server pod logs.
That means we need a little ingenuity to view the log output created by the lockdown list; statement. Let's see how to do this with kubectl logs statements from a bash shell prompt. You could also find the log output from autoexec code with a log monitoring tool such as OpenSearch Dashboards in SAS Viya Monitoring for Kubernetes. Other log monitoring tools configured for use with SAS Viya should also be able to find sas-compute-server pod logs just as easily as any other pod logs.
Add a lockdown list statement to a compute context autoexec
I'm going to just add a SAS code statement to a compute context's autoexec code block in SAS Environment Manager. But of course you can also do this programmatically. If you prefer that, see my article Add statements to an existing SAS compute context autoexec, which presents a bash function called add_code_to_compute_context_autoexec(), which you could use to do that, as well as how to do it interactively in SAS Environment Manager. The article even uses a lockdown path statement in its usage example for the function.
Open SAS Environment Manager and sign in as a SAS Administrator, so that you see the Contexts page. Select Contexts, and from the View dropdown menu, choose Compute contexts. Edit the SAS Studio compute context (or another compute context if you prefer).
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
In the Edit Compute Context dialog, switch to the Advanced tab. The field labelled "Autoexec content:" contains the autoexec code statements that are run as compute sessions under this compute context start. Add a lockdown list; statement to the autoexec content textbox:
Save your changes.
Start a compute session, and identify the sas-compute-server pod in which it is running.
Open SAS Studio. You can do this step as the SAS Administrator, but you can use any user who can start a compute session for this step.
When you open SAS Studio, a new compute session starts. Make sure it is running under the compute context which you modified to have a lockdown list statement in its autoexec; switch to that compute context if necessary.
If you already had a compute session under the right compute context running, you might need to sign out and sign in again, or choose Options > Reset SAS Session from the menu bar in SAS Studio so that a new session starts. During initialization, the newly modified autoexec code is executed, and your lockdown list statement should be run as part of that.
You will not see any output from that lockdown statement in the log panel in SAS Studio. But you can find it in the pod logs.
If you don't have any other compute server pods running at that moment, it is easy to identify which pod your new compute session is running in. If you have other compute server pods, we should identify which sas-compute-server-guid pod which is running your compute session. There are several ways to do this, and one is to run this SAS macro statement in SAS Studio program window:
%put NOTE: My SAS Compute Server POD IS &SYSHOSTNAME;
Expected output:
80 %put NOTE: My SAS Compute Server POD IS &SYSHOSTNAME;
NOTE: My SAS Compute Server POD IS sas-compute-server-9fd701ea-49bb-4aa8-a963-44406ad65108-108
Copy the pod name (e.g. sas-compute-server-9fd701ea-49bb-4aa8-a963-44406ad65108-108 in the example output above) to a text editor, or even just to the clipboard. We will use it in a moment.
Find the pod logs, and the lockdown paths statements, for your sas-compute-server pod
From a bash shell prompt, run this series of bash commands, substituting the name of your compute server pod for the value of pod_name in the first line:
pod_name="sas-compute-server-9fd701ea-49bb-4aa8-a963-44406ad65108-108"
lines_before_LOCKDOWN=30
kubectl logs ${pod_name} \
| grep -B ${lines_before_LOCKDOWN} LOCKDOWN \
| jq -R -r '. as $line | try (fromjson| "\(.level | ascii_upcase) \(.timeStamp) '['\(.source)']-' \(.message) " ) catch $line '
The last part of the third line, starting from jq onwards, reformats the JSON structured logging documents output by the SAS compute server to a more human-readable format.
You might have to adjust the value for lines_before_LOCKDOWN when you run this, to be sure you have all of the paths in the lockdown paths list. Make sure you see a line saying "NOTE: These pathnames can be accessed when SAS is in the lockdown state:" before the first path in your output, and at least one line saying "NOTE: The LOCKDOWN option has been set. SAS is now in the lockdown state." after the last one.
Expected output might be something like this:
INFO 2025-10-02T11:40:38.487000+00:00 [compsrv]- Engine: V9
INFO 2025-10-02T11:40:38.487000+00:00 [compsrv]- Physical Name: /gelcontent/gelcorp/sales/data
INFO 2025-10-02T11:40:38.488000+00:00 [compsrv]- NOTE: DATA statement used (Total process time):
INFO 2025-10-02T11:40:38.488000+00:00 [compsrv]- real time 0.00 seconds
INFO 2025-10-02T11:40:38.488000+00:00 [compsrv]- cpu time 0.00 seconds
INFO 2025-10-02T11:40:38.488000+00:00 [compsrv]-
INFO 2025-10-02T11:40:38.488000+00:00 [compsrv]- NOTE: AUTOEXEC processing completed.
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- NOTE: These pathnames can be accessed when SAS is in the lockdown state:
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /opt/sas/viya/home/share/fonts
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /usr/lib/jvm/java-17-openjdk-17.0.14.0.7-3.el8.x86_64/lib/fonts
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /opt/sas/viya/home/SASFoundation
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /security/trustedcerts.pem
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /security/tls.crt
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /usr/local/share/lua/5.2
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- 2 The SAS System Thursday, October 2, 2025 11:40:00 AM
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /usr/local/lib/lua/5.2
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /compute_data
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /opt/sas/viya/home/share/refdata/qkb
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /tmp
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /config
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /shared/gelcontent/home/sasadm
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /opt/sas/viya/config/var
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /opt/sas/viya/home/lib64
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /opt/sas/viya/config/data/modelsvr/resources
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /rdutil
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /opt/sas/viya/config/data/modelsvr/astore
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /sashelp
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /opt/sas/viya/home/commonfiles
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /sasuser
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- /gelcontent
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- NOTE: The LOCKDOWN option has been set. SAS is now in the lockdown state.
INFO 2025-10-02T11:40:38.489000+00:00 [compsrv]- NOTE: The LOCKDOWN option has been set. SAS is now in the lockdown state.
From this output, we can see that the following paths are in the lockdown paths list in my environment:
/opt/sas/viya/home/share/fonts
/usr/lib/jvm/java-17-openjdk-17.0.14.0.7-3.el8.x86_64/lib/fonts
/opt/sas/viya/home/SASFoundation
/security/trustedcerts.pem
/security/tls.crt
/usr/local/share/lua/5.2
/usr/local/lib/lua/5.2
/compute_data
/opt/sas/viya/home/share/refdata/qkb
/tmp
/config
/shared/gelcontent/home/sasadm
/opt/sas/viya/config/var
/opt/sas/viya/home/lib64
/opt/sas/viya/config/data/modelsvr/resources
/rdutil
/opt/sas/viya/config/data/modelsvr/astore
/sashelp
/opt/sas/viya/home/commonfiles
/sasuser
/gelcontent
This might be a longer list of paths than you would expect. These paths are required by various parts of the SAS programming run-time code execution environment for it to all function properly. They all refer to paths inside the compute server pod's sas-programming-environment container, of course, rather than paths on any host machine.
In my environment, when this output was captured, I did not have any lockdown paths statements in either the global Compute Service autoexec configuration instance (sas.compute.server: autoexec_code), or in my compute context autoexec code, which is shown above. I did however have an NFS volume mounted into the environment, using a transformer referenced from my kustomization.yaml file, pointing to site-config/compute-server-add-nfs-mount.yaml. That file defines a PatchTransformer mounting a volume at the path /gelcontent. Notice how the /gelcontent path is one of the paths listed above. It was automatically added to the list.
Optional: get fancy with advanced bash commands
There are other ways to identify a pod running for a user, and bash commands can be run as subcommands in other bash commands. For example, the rather complex example below uses kubectl get pods with some label selectors, a field selector and a jsonpath output format modifier to find the most recently-started running compute pod requested by username sasadm, passes it to a kubctl logs command, greps the output to search for lines near the first note in the output from lockdown list; uses jq to show just the timestamp and the message from the structured log documents, and the bash paste command to join the jq output back together on one line, all in one command:
kubectl logs $(kubectl get pods -l launcher.sas.com/requested-by-client=sas.studio,launcher.sas.com/username=sasadm --field-selector status.phase=Running --sort-by=.metadata.creationTimestamp --output=jsonpath={.items..metadata.name}) -c='sas-programming-environment' \
| grep -i -B 3 -A 30 'These pathnames can be accessed when SAS is in the lockdown state' \
| jq -r '.timeStamp, .message' \
| paste -d ' ' - -
The lockdown allowlist paths output is somwhat similar to the example output shown before, but not identical. You can get quite creative with these sorts of things if you are interested in bash scripting, and I would encourage you to have a play around, but it's also fine to keep it simple. We'll keep it simple for the rest of this post.
Find a path not in the lockdown allowlist
To have something to demonstrate, I wanted to find a path that exists inside my sas-compute-server pod, but which is not already in the lockdown paths allowlist. To do that, I exec'ed into the sasadm user's compute server pod, running an interactive bash shell, with a command like this:
kubectl exec -it \
$(kubectl get pod -l launcher.sas.com/requested-by-client=sas.studio,launcher.sas.com/username=sasadm \
--output=jsonpath={.items..metadata.name}) \
-c "sas-programming-environment" \
-- bash
Using ordinary bash commands like pwd, ls, cd and so on interactively, I found a path that was present in the pod/container, but not in the lockdown allow list: /opt/sas/viya/config/etc/compsrv/default. For the purposes of a demonstration I'll add it to my allowlist, but this is a unwise thing do to in a production environment.
Exit the shell session runing inside the sas-programming-runtime container by typing the command: exit
First, let's run a bit of SAS code in SAS Studio to demonstrate that we cannot read the file /opt/sas/viya/config/etc/compsrv/default/sasv9.cfg because it is not in the LOCKDOWN allowlist of paths.
In SAS Studio, run this:
%put NOTE: My SAS Compute Server POD IS &SYSHOSTNAME;
filename sasv9cfg "/opt/sas/viya/config/etc/compsrv/default/sasv9.cfg";
data sasv9cfg;
length text $256;
infile sasv9cfg truncover dsd;
input text $;
run;
proc print data=sasv9cfg;
run;
You should see log output something like this, which includes the message "/opt/sas/viya/config/etc/compsrv/default/sasv9.cfg is not in the list of accessible paths when SAS is in the lockdown state.", and some other associated errors:
80 %put NOTE: My SAS Compute Server POD IS &SYSHOSTNAME;
NOTE: My SAS Compute Server POD IS sas-compute-server-414dee10-68b5-4f2d-a06f-83f05ecf6553-197
81
82 filename sasv9cfg "/opt/sas/viya/config/etc/compsrv/default/sasv9.cfg";
ERROR: The path /opt/sas/viya/config/etc/compsrv/default/sasv9.cfg is not in the list of accessible paths when SAS is in the
lockdown state.
ERROR: Error in the FILENAME statement.
83 data sasv9cfg;
84 length text $256;
85 infile sasv9cfg truncover dsd;
86 input text $;
87 run;
ERROR: No logical assign for filename SASV9CFG.
NOTE: The SAS System stopped processing this step because of errors.
WARNING: The data set WORK.SASV9CFG may be incomplete. When this step was stopped there were 0 observations and 1 variables.
Add /opt/sas/viya/config/etc/compsrv/default to the Lockdown allowlist
For this demonstration I'll add /opt/sas/viya/config/etc/compsrv/default to the lockdown allowlist, but again, this is not a wise thing to do in a production environment. However, there are plenty of more dangerous paths an unscrupulous or misguided administrator could add. If we were being really reckless, we could add /etc, /root, /opt or even just / to the paths list. Don't do any of these things if you care at all about your pods remaining secure.
Open SAS Environment Manager (Manage Environment).
Since I'm happy to limit this to just one compute context, I'll again edit the SAS Studio Compute context, to add the following statement to the Autoexec code block. You could also add this to the global Compute Server autoexec code block, to make it affect all compute sessions under all compute contexts. Add this to your SAS Studio compute context, in the Autoexec content textbox, anywhere before the lockdown list; statement:
lockdown path='/opt/sas/viya/config/etc/compsrv/default';
Here's what this looks like in my environment:
Save your changes.
Then, back in SAS Studio (Develop Code and Flows), either choose Options > Reset SAS session, or sign out and sign in again, so that a new compute server is started and during initialization, the new path will be added to its lockdown paths list.
Once you have a new compute session running, in a SAS Program window, run the same program we ran a moment ago:
%put NOTE: My SAS Compute Server POD IS &SYSHOSTNAME;
filename sasv9cfg "/opt/sas/viya/config/etc/compsrv/default/sasv9.cfg";
data sasv9cfg;
length text $256;
infile sasv9cfg truncover dsd;
input text $;
run;
proc print data=sasv9cfg;
run;
This time should see some results that look something like this, showing the sasv9.cfg file could be successfully read:
On the Log tab, the log messages are now free of errors:
80 %put NOTE: My SAS Compute Server POD IS &SYSHOSTNAME;
NOTE: My SAS Compute Server POD IS sas-compute-server-93cdd791-f8fb-4ff5-a648-a0dd96e1169e-231
81
82 filename sasv9cfg "/opt/sas/viya/config/etc/compsrv/default/sasv9.cfg";
83 data sasv9cfg;
84 length text $256;
85 infile sasv9cfg truncover dsd;
86 input text $;
87 run;
NOTE: The infile SASV9CFG is:
Filename=/opt/sas/viya/config/etc/compsrv/default/sasv9.cfg,
Owner Name=sas,Group Name=sas,
Access Permission=-rw-r--r--,
Last Modified=03Mar2025:05:14:18,
File Size (bytes)=394
NOTE: 14 records were read from the infile SASV9CFG.
The minimum record length was 0.
The maximum record length was 81.
NOTE: The data set WORK.SASV9CFG has 14 observations and 1 variables.
NOTE: DATA statement used (Total process time):
real time 0.00 seconds
cpu time 0.01 seconds
88 proc print data=sasv9cfg;
89 run;
NOTE: There were 14 observations read from the data set WORK.SASV9CFG.
NOTE: The PROCEDURE PRINT printed page 3.
NOTE: PROCEDURE PRINT used (Total process time):
real time 0.00 seconds
cpu time 0.01 seconds
You could add other paths to the lockdown paths list in a similar way, or by adding lockdown path statements to the global compute server autoexec. If we re-run one of the bash commands above, we can see that this path is now listed in the output of the lockdown list; statement in the SAS Studio compute context autoexec too. Remember to use the most recent pod name - it is different to the pod name we looked at logs for earlier:
pod_name="sas-compute-server-93cdd791-f8fb-4ff5-a648-a0dd96e1169e-231"
lines_before_LOCKDOWN=30
kubectl logs ${pod_name} \
| grep -B ${lines_before_LOCKDOWN} LOCKDOWN \
| jq -R -r '. as $line | try (fromjson| "\(.level | ascii_upcase) \(.timeStamp) '['\(.source)']-' \(.message) " ) catch $line '
Expected output:
INFO 2025-10-02T13:30:27.206000+00:00 [compsrv]- Physical Name: /gelcontent/gelcorp/sales/data
INFO 2025-10-02T13:30:27.207000+00:00 [compsrv]- NOTE: DATA statement used (Total process time):
INFO 2025-10-02T13:30:27.207000+00:00 [compsrv]- real time 0.00 seconds
INFO 2025-10-02T13:30:27.207000+00:00 [compsrv]- cpu time 0.01 seconds
INFO 2025-10-02T13:30:27.207000+00:00 [compsrv]-
INFO 2025-10-02T13:30:27.208000+00:00 [compsrv]- NOTE: AUTOEXEC processing completed.
INFO 2025-10-02T13:30:27.208000+00:00 [compsrv]- NOTE: These pathnames can be accessed when SAS is in the lockdown state:
INFO 2025-10-02T13:30:27.208000+00:00 [compsrv]- /opt/sas/viya/home/share/fonts
INFO 2025-10-02T13:30:27.208000+00:00 [compsrv]- /usr/lib/jvm/java-17-openjdk-17.0.14.0.7-3.el8.x86_64/lib/fonts
INFO 2025-10-02T13:30:27.208000+00:00 [compsrv]- /opt/sas/viya/home/SASFoundation
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /security/trustedcerts.pem
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /security/tls.crt
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /usr/local/share/lua/5.2
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- 2 The SAS System Thursday, October 2, 2025 01:30:00 PM
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /usr/local/lib/lua/5.2
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /compute_data
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /gelcontent
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /opt/sas/viya/config/data/modelsvr/resources
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /opt/sas/viya/config/data/modelsvr/astore
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /opt/sas/viya/home/lib64
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /opt/sas/viya/home/commonfiles
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /opt/sas/viya/home/share/refdata/qkb
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /tmp
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /sashelp
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /opt/sas/viya/config/var
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /sasuser
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /config
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /rdutil
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /shared/gelcontent/home/sasadm
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- /opt/sas/viya/config/etc/compsrv/default
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- NOTE: The LOCKDOWN option has been set. SAS is now in the lockdown state.
INFO 2025-10-02T13:30:27.209000+00:00 [compsrv]- NOTE: The LOCKDOWN option has been set. SAS is now in the lockdown state.
The list of paths is not sorted in any particular order, and the order in which paths are listed may vary from one compute session to the next, but in the output above, you can see that /opt/sas/viya/config/etc/compsrv/default is now in the lockdown paths list.
What about volumes mounted into compute server pods?
As I mentioned earlier, the path /gelcontent is in the lockdown allowlist in my environment because it is the mount path for a volume which we have mounted into compute server pods for the class environment I'm using. To illustrate this, let's create another directory under our existing /shared NFS fileshare, called demo. I gave it similar permissions to /shared/gelcontent, but of course you you should consider the permissions which are appropriate for this directory and set them up accordingly.
sudo mkdir /shared/demo
sudo chmod 777 /shared/demo
sudo chown sas /shared/demo
sudo chgrp sasusers /shared/demo
Having created the new demo directory under /shared on the host where our NFS file server is running, we can add a line to /etc/exports on that host, to define a new export:
/srv/nfs/kubedata *(rw,sync,no_subtree_check,no_root_squash,insecure)
/shared/gelcontent *(rw,sync,no_root_squash,insecure)
/shared/demo *(rw,sync,no_root_squash,insecure)
And then we can tell NFS to re-read its config file, which (all being well) should result in NFS sharing the new fileshare /shared/demo:
sudo exportfs -a
Since my workshop environment already has a site-config/compute-server-add-nfs-mount.yaml file which adds an NFS volume and mounts it into compute server pods, I can add extra patch operators to that existing file to add a second NFS mount, so that the modified file looks like this with the new part in bold:
---
apiVersion: builtin
kind: PatchTransformer
metadata:
name: compute-server-add-nfs-mount
patch: |-
- op: add
path: /template/spec/volumes/-
value:
name: sas-viya-gelcorp-volume
nfs:
path: /shared/gelcontent
server: pdcesx41538.race.sas.com
- op: add
path: /template/spec/containers/0/volumeMounts/-
value:
name: sas-viya-gelcorp-volume
mountPath: /gelcontent
- op: add
path: /template/spec/volumes/-
value:
name: sas-viya-demo-volume
nfs:
path: /shared/demo
server: pdcesx41538.race.sas.com
- op: add
path: /template/spec/containers/0/volumeMounts/-
value:
name: sas-viya-demo-volume
mountPath: /demo
target:
kind: PodTemplate
version: v1
labelSelector: sas.com/template-intent=sas-launcher
There was no need to add a reference to this PatchTransformer yaml file to my kustomization.yaml, because it is already referenced.
Then I re-deployed SAS Viya in the same way as usual for this environment. (I use the sas-orchestration tool's deploy command, but you should use whatever method is usual for your environment).
When the redeployment has finished, I opened SAS Studio again, signed in as sasadm, and waited for the compute session to start. To get the compute pod name, we run the same SAS code statement we ran before:
From my bash shell, let's run the same commands as before.
%put NOTE: My SAS Compute Server POD IS &SYSHOSTNAME;
Then, using that pod name as the value in, we can run this from the bash shell to see the relevant part of the pod logs, listing the lockdown paths:
pod_name="sas-compute-server-8823e6d1-c1b6-4b38-babd-f36acacbee5f-281"
lines_before_LOCKDOWN=30
kubectl logs ${pod_name} \
| grep -B ${lines_before_LOCKDOWN} LOCKDOWN \
| jq -R -r '. as $line | try (fromjson| "\(.level | ascii_upcase) \(.timeStamp) '['\(.source)']-' \(.message) " ) catch $line '
Expected output:
INFO 2025-10-02T14:21:10.068000+00:00 [compsrv]- NOTE: DATA statement used (Total process time):
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- real time 0.00 seconds
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- cpu time 0.00 seconds
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]-
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- NOTE: AUTOEXEC processing completed.
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- NOTE: These pathnames can be accessed when SAS is in the lockdown state:
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- /opt/sas/viya/home/share/fonts
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- /usr/lib/jvm/java-17-openjdk-17.0.14.0.7-3.el8.x86_64/lib/fonts
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- /opt/sas/viya/home/SASFoundation
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- /security/trustedcerts.pem
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- /security/tls.crt
INFO 2025-10-02T14:21:10.069000+00:00 [compsrv]- /usr/local/share/lua/5.2
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- 2 The SAS System Thursday, October 2, 2025 02:21:00 PM
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /usr/local/lib/lua/5.2
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /compute_data
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /opt/sas/viya/config/data/modelsvr/resources
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /shared/gelcontent/home/sasadm
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /opt/sas/viya/home/commonfiles
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /demo
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /opt/sas/viya/config/var
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /config
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /gelcontent
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /opt/sas/viya/home/share/refdata/qkb
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /sashelp
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /rdutil
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /opt/sas/viya/config/data/modelsvr/astore
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /tmp
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /opt/sas/viya/home/lib64
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /sasuser
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- /opt/sas/viya/config/etc/compsrv/default
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- NOTE: The LOCKDOWN option has been set. SAS is now in the lockdown state.
INFO 2025-10-02T14:21:10.070000+00:00 [compsrv]- NOTE: The LOCKDOWN option has been set. SAS is now in the lockdown state.
Note that the /demo path is now in the lockdown paths allowlist.
However, since we created the /shared/demo directory on the NFS file server host, shared it and mounted it as a volume at a path of /demo in our SAS Viya programming run-time pods, we have not added a lockdown path statement to our autoexec code anywhere. We have not explicitly told our SAS Viya deployment to add the /demo path to the lockdown allow list, but the /demo path is now in the lockdown allow list.
This shows that it is not necessary to add lockdown path statements to your autoexec code blocks for volumes mounted into compute pods, as they are automatically added to the lockdown paths list.
That came as news to me and several members of my team within SAS. I was surprised to 'discover' this fact, though I subsequently confirmed with our developers in R&D that this was intended behavior and has been since SAS Viya was released.
Every day is a schoolday, and it is better to know these things than not to, so I wanted to share this more widely.
See you next time!
Find more articles from SAS Global Enablement and Learning here.
