I'm not really sure how this is possible, but we have seen the case that os.getgroups() returns gids, which are not resolveable by grp.getgrid():
Traceback (most recent call last):
File "/usr/local/bin/ws_find", line 64, in <module>
groups = [grp.getgrgid(gid_tmp)[0] for gid_tmp in os.getgroups()]
File "/usr/local/bin/ws_find", line 64, in <listcomp>
groups = [grp.getgrgid(gid_tmp)[0] for gid_tmp in os.getgroups()]
KeyError: 'getgrgid(): gid not found: 500468'
Traceback (most recent call last):
File "/usr/local/bin/ws_list", line 103, in <module>
groups = [grp.getgrgid(gid_tmp)[0] for gid_tmp in os.getgroups()]
File "/usr/local/bin/ws_list", line 103, in <listcomp>
groups = [grp.getgrgid(gid_tmp)[0] for gid_tmp in os.getgroups()]
KeyError: 'getgrgid(): gid not found: 500468'
In this case the gid 500468 was not existing in /etc/group due to a temporary synchronisation issue of the cluster.
A possible workaround could be ignoring the invalid secondary group:
groups = []
for gid_tmp in os.getgroups():
try:
groups.append(grp.getgrgid(gid_tmp)[0])
except KeyError:
print(f"group {gid_tmp} could not be resolved - ignoring", file=sys.stderr)
Or maybe it is better (and safer) to abort the complete call of ws_list ?
I'm not really sure how this is possible, but we have seen the case that os.getgroups() returns gids, which are not resolveable by grp.getgrid():
In this case the gid 500468 was not existing in /etc/group due to a temporary synchronisation issue of the cluster. A possible workaround could be ignoring the invalid secondary group:
Or maybe it is better (and safer) to abort the complete call of
ws_list
?best, Sven