Opened 17 years ago

Last modified 9 years ago

#82 new enhancement

IZ459: userset '@' notation only checks primary UNIX group

Reported by: saalwaechter Owned by:
Priority: normal Milestone:
Component: sge Version: 5.3p2
Severity: Keywords: qmaster
Cc:

Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=459]

        Issue #:      459              Platform:     All           Reporter: saalwaechter (saalwaechter)
       Component:     gridengine          OS:        All
     Subcomponent:    qmaster          Version:      5.3p2            CC:
                                                                             [_] uddeborg
                                                                             [_] Remove selected CCs
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     ernst
          URL:
       * Summary:     userset '@' notation only checks primary UNIX group
   Status whiteboard:
      Attachments:

     Issue 459 blocks:
   Votes for issue 459:  10


   Opened: Mon Jan 20 16:06:00 -0700 2003 
------------------------


RFE = Have SGE somehow honor both primary and
secondary UNIX groups when evaluating the userset
'@' notation.

Details =

From Nov-2002 dev@gridengine.sunsource.net
mailing list…

Andy = Andy Schwierskott
John = John Saalwaechter
Subject: userset '@' notation only checks primary
UNIX group

*** John ***:
In defining usersets, the documentation states
that @foo will include users in the UNIX group
named 'foo'.  This is only working for users
whose *primary* UNIX group is foo.  Users with
foo as a *secondary* UNIX group are not being
properly added to the userset.  In my
environment, it's common for users to belong
to three or more groups.

I'm trying this with SGEEE5.3p2.

To implement the '@' notation, I would have
expected a call somewhere to getgrnam(),
followed by an access to the gr_mem member
of the group struct.  I downloaded the
source, and I didn't find any reference
to gr_mem.

I would consider this issue a bug based
on the access_list(5) man page.

*** Andy ***:
I understand why you (and in the past other
sites) requested the behavior as you expect.
Let me explain why it's not a bug.

In a SGE cluster we explicitly do not
assume that the user exists at the qmaster
machine. Therefore no username and no group
name resolving is done at the qmaster machine.
This behavior is needed for sites which have
heterogeneous username resolving (e.g. no
centralized with NIS) [Note: this scheme
also fits for sites which deploy the SGE
Openssl security framework]

*** John ***:
OK, I can understand that.

*** Andy ***:
Resolving usernames/groupnames is an
expensive operation (-> NIS queries
usually). Since group names may change
during the life time of a job it would
be necessary to resolve such names
probably quite frequently. For sites
where the username does not exist at
the qmaster machine this even wouldn't
work.

*** John ***:
Agreed, however, as you stated above,
the qmaster isn't looking up
usernames/groupnames.  I assume that
submit and/or exec hosts are
doing the lookups and passing
usernames/groupnames to the qmaster
as strings for comparison against
SGE users/usersets.  So at least
the NIS load is spread around.
Perhaps a relatively efficient scheme
could be devised where SGE only checks
secondary groups if the submitted or
primary group results in errors like
'job rejected: no access to "ProjectX"
for user "frank"'.  Such a feature
could be controlled by a global
configuration option.

*** Andy ***:
I think the effort for an admin to
configure a solution which fits your
requirements is acceptable: instead
of having only one group in the access
list (@group1), you only need to add
all these groups to the access list
(@group1 @group2 ...).

*** John ***:
I disagree.  Imagine hundreds of
users each with a primary UNIX group
set to their department's UNIX group.
Now imagine that large projects also
get a UNIX group id.  User Frank may
have a primary group of deptA with
secondary groups projX, projY, projZ.
User Mary may have primary group deptB
with secondary groups projX, projQ,
projP.  If I wanted to define a project
in SGEEE assigned to Project X, I would
want to make a userset with @projX.
Because the project UNIX groups are
secondary for users, however, according
to your suggestion I would create an
SGEEE userset that consisted of
(@projX,@deptA,@deptB).  Now I'm being
too inclusive though, and adding *all*
users of departments A and B in the
userset.

*** Andy ***:
Ok, this is of course not what you
want.

In this case I only can suggest
a solution which one of our customers
uses since many years. It requires admins
to setup some scripts to automate the
process but it works: The script(s)
could create user access lists from the
information found in passwd and
group files. These access lists are then
added (or do modify) to the SGE
access_lists.

*** John ***:
Having SGEEE (optionally) honor both
primary and secondary groups cleanly
resolves this problem from a user and
administrator perspective.  It adheres
to the principle of least surprise.

*** Andy ***:
I agree that that the feature may
make sense for site like yours. Could
you please file a RFE for Issuezilla
(please add your example above and your
suggestion below to this Issue). Having
such needs documented in Issuezilla
is the best way to ensure that
discussions and ideas exchanged on our
mailing lists get some "persistence".

*** Andy ***:
Of course a user may submit his job
under another primary group as well.
There are sites which have the
requirement that the job is started
under the submission primary group id.
By default SGE sets the primary group
id from passwd. If the primary
submission group id should be set,
the global cluster config parameter
execd_params "USE_QSUB_GID" value
can be set to enforce setting of the
submission group id as primary group id.

*** John ***:
I think you're suggesting that
users can run newgrp before submitting
jobs. That might be OK, except that
most users these days no longer use
or know about newgrp.  This is because
1) basic file permission enforcement
considers all of a user's groups, and
2) the commonly used BSD semantics for
setgid on directories silently propagates
group id's effectively.  Another downside
of newgrp is that it creates a new
subshell, which may surprise unfamiliar
users.

Maybe a good compromise solution
(that should be efficient) is to add a
common command-line option to qsub and
related commands that lets a user specify
which of their gids to submit under.
The command could verify the user's
membership in that group before proceeding.
For example,

$ qsub -gid projX -P Project_X jobscript

I didn't find such an option in the qsub
man page, so let me know if I missed it.

*** Andy ***:
No, SGE does not have that option.

   ------- Additional comments from sgrell Mon Dec 12 03:04:21 -0700 2005 -------
Changed the subcomponent.

Stephan

   ------- Additional comments from uddeborg Fri Mar 23 03:48:40 -0700 2007 -------
There is something strange in the reasoning here.  If you can find the primary
group, you should also be able to find supplementary groups.  Why is the fact
that a user may not exist at qmaster a problem for supplementary gruoups, but
not for the primary group?

   ------- Additional comments from andreas Fri Mar 23 05:13:15 -0700 2007 -------
You are right one could implement it.

The reason for me to argue against is that it would require the names of all
suppl group ids be stored by qmaster, but if only a specified group needed be
passed with the job to qmaster, as you suggest, it wouldn't impact qmaster
memory footprint.

Note, sending the group id name to qmaster is always necessary. If the group
name is not sent qmaster had to resolve grop ID into group name for each job.
This would cause a severe job submission delay in qmaster.

Change History (0)

Note: See TracTickets for help on using tickets.