holgerBerger / hpc-workspace

Automatically exported from code.google.com/p/hpc-workspace
GNU General Public License v3.0
18 stars 13 forks source link

ws_list/ws_find: handling not existing usergroups #76

Closed URZ-HD closed 1 year ago

URZ-HD commented 3 years ago

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 ?

best, Sven