Opened 19 years ago

Last modified 11 years ago

#21 new enhancement

IZ196: improve qconf -muser sanitity checking wrt access permission to default project

Reported by: andy Owned by:
Priority: low Milestone:
Component: sge Version: 5.3beta2
Severity: Keywords: qmaster


[Imported from gridengine issuezilla]

        Issue #:      196              Platform:     All           Reporter: andy (andy)
       Component:     gridengine          OS:        All
     Subcomponent:    qmaster          Version:      5.3beta2         CC:    None defined
        Status:       REOPENED         Priority:     P4
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     ernst
       * Summary:     improve qconf -muser sanitity checking wrt access permission to default project
   Status whiteboard:

     Issue 196 blocks:
   Votes for issue 196:

   Opened: Fri Mar 15 07:05:00 -0700 2002 

E.g. it is possible to add a default project to a user object in SGEEE,
however this user is not able via the access list of the project to run any jobs
in this default project.

There should be at least warning for such non-useful configs.

The same problem may occur for other objects as well.

   ------- Additional comments from andreas Thu Dec 11 08:35:09 -0700 2003 -------
HOWTOFIX: need sanitiy checking here

   ------- Additional comments from templedf Thu Mar 4 09:19:29 -0700 2004 -------
This no longer appears to be a problem...

balin:/tmp/dant 51 % cat test
name dant
oticket 0
fshare 0
default_project default
balin:/tmp/dant 52 % qconf -Auser test
denied: project "default" does not exist

   ------- Additional comments from andreas Fri Mar 5 08:01:18 -0700 2004 -------
Changed summary to more clearly point to the actual problem.

Unfortunately sanity checking can't always be performed in
a way really ensuring the user will have access to it's default
project. This is because access lists determining the projects
access permissions might use not only user names but also group
names. Whilst the user name is known at the time when this
verification needs to be done the group name isn't ...
... nevertheless the sanity check should be done in those cases
when actually no group is refered by the projects access lists.

Won't be fixed for 6.0 beta.

   ------- Additional comments from andreas Mon Mar 29 04:51:04 -0700 2004 -------

   ------- Additional comments from andreas Mon May 3 11:50:03 -0700 2004 -------
Lowering priority.

   ------- Additional comments from sgrell Tue Dec 6 04:02:38 -0700 2005 -------
Changed subcomponent.


   ------- Additional comments from ernst Tue Dec 6 12:30:39 -0700 2005 -------
Changed Issue Type

Change History (0)

Note: See TracTickets for help on using tickets.