Here is a bit more detail about what is happening.
For a job to be accepted by the PBS server, the user at the submitting host must pass an ruserok() test.
From the RCMD(3) man page:
The iruserok() and ruserok() functions take a remote host’s IP address or name, respectively, two user names and a flag indicating whether the local user’s name is that of the superuser. Then, if the user is NOT the superuser, it checks the /etc/hosts.equiv file. If that lookup is not done, or is unsuccessful, the .rhosts in the local user’s home directory is checked to see if the request for service is allowed.
If this file does not exist, is not a regular file, is owned by anyone other than the user or the superuser, or is writeable by anyone other than the owner, the check automatically fails. Zero is returned if the machine name is listed in the hosts.equiv file, or the host and remote user name are found in the .rhosts file; otherwise iruserok() and ruserok() return -1. If the local domain (as obtained from gethostname(2)) is the same as the remote domain, only the machine name need be specified.
If the pbs_server attribute flatuid is set to true, this test is skipped and the job is accepted based on the submitting users name alone (with obvious security implications: a rogue user on a system that they control could create a user account with the same name as someone else and submit jobs as that user; if this is a concern but for whatever reason you don’t want to set things up that ruserok() passes, consider using the PBS server attributes acl_host_enable and acl_hosts to whitelist trusted job submission hosts where the user accounts are trusted).
Flatuid set to true or not, to run as a user other than the job owner (the submitter) you must have authorization to do so via ruserok(). Otherwise, any user could run a job as any other user. You authorize for userA to run a job as userB the same way you authorize userA@host1 to run a job as userA on host2 when flatuid is Not SET, i.e. see .ruserok() and .rhosts.
Finally, I don’t think you need it here, but to make this post more complete and useful I will include a simple test program I have used in troubleshooting over the years to see if ruserok() passes for a given user and host:
/*
Two use cases:
1) User submitting job from remote host to server getting unexpected
"Bad UID" message. That is, user doesn't have access when he thinks
he should.
2) User(s) can delete, etc other user(s) jobs. That is, one user is able
to act as what he thinks is a different user, server sees them as
being equivalent.
Build with "cc ruserok.c -o ruserok"
Usage (run on the PBS server system):
ruserok remote_host remote_user1 local_user2
where:
remote_host: the host from which the job is being submitted, or where the PBS client command is issued
remote_user1: the username of the user submitting the job, or issuing the client command
loca_user2: the username of the user remote_user1 is trying to submit the job as, or owner of the job that remote_user1 is trying to act on with the client command
*/
#include <errno.h>
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
int rc;
char hn[257];
if (argc != 4) {
fprintf(stderr, "Usage: %s remote_host remote_user1 local_user2\n", argv[0]);
return 1;
}
if (gethostname(hn, 256) < 0) {
perror("unable to get hostname");
return 2;
}
hn[256] = '\0';
printf("on local host %s, from remote host %s\n", hn, argv[1]);
rc = ruserok(argv[1], 0, argv[2], argv[3]);
if (rc == 0)
printf("remote user %s is allowed access as local user %s\n", argv[2], argv[3]);
else
printf("remote user %s is denied access as local user %s\n", argv[2], argv[3]);
return 0;
}