-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zFS for zssServer must be mounted with SETUID option #807
Comments
For whoever picks this up, I have REXX code that uses SYSCALL to test for SETUID, among other things, |
Something like this should be ok, example of output for zFS mounted with
|
Using "df -v" means you have to parse command output, which might change over time, or differ with different code pages or shells, so it is not a valid option for testing whether SETUID is set or not.
|
A lot of internal logic depends on shell commands output... I am preferring either shell function or JS function (if not already there). Another option is to check only
if [ "$ZWE_components_zss_agent_64bit" = "true" ] && [ -x "${ZSS_SERVER_64}" ]; then
ZSS_SERVER="${ZSS_SERVER_64}"
else
ZSS_SERVER="${ZSS_SERVER_31}"
fi
if [ -z $(extattr "${ZSS_SERVER}" | grep 'Program controlled = YES') ]; then
echo "Some warning message"
fi
|
I prefer the JS function and we owe an investigation of whether this is available programmatically. |
I have a working prototype in JS: import * as zos from 'zos';
const PATHS = [ './', '/', '/bin/', '', null, true, false ];
for (let p = 0; p < PATHS.length; p++) {
const result = zos.getStatvfs(PATHS[p]);
console.log(`===> "${PATHS[p]}"`);
console.log(`Stats=${JSON.stringify(result[0])}`);
console.log(`RC=${result[1]}\n`);
}
|
I like doing this check at install, init, AND launcher startup to catch config changes. |
Doing the test during install does not make sense for larger customers as they would install on a test system and then deploy to the target systems. Also, SMP/E install of Zowe would not do this, unless you provide a script SMPE must run when it processes a specific file. |
The SETUID requirement is valid for all environments where the customer want to run Zowe. Checking the mount options in the sandbox won't help if the customer mounted the zFS with NOSETUID in production. The check should happen at least once on after initial install and any release upgrade. I don't know the best location for this check. |
How about you run it AFTER startup? The startup process can check the server RC and run the SETUID check only when needed (RC not 0) for all related directories (/bin, /usr/lpp/zowe, /usr/lpp/java). |
zssServer runs program controlled which requires that the zFS is mounted with option SETUID.
If the zFS is mounted with option NOSETUID zssServer is no longer program controlled and certain API calls can fail with
BPXTLS failed: rc=-1, return code=139, reason code=0x0be802af
I suggest to modify the relevant install script to check if the zFS mount where zssServer is installed is mounted with SETUID option. I am not sure how to do it, but it might be possible to script over "df -v ".
See information on SETUID/NOSETUID here: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/tsomount.htm
The text was updated successfully, but these errors were encountered: