Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (28 - 30 of 431)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Ticket Resolution Summary Owner Reporter
#486 fixed IZ2482: sge_qquota not processed properly Dave Love <d.love@…> clarinet
Description

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

        Issue #:      2482             Platform:     PC       Reporter: clarinet (clarinet)
       Component:     gridengine          OS:        Linux
     Subcomponent:    clients          Version:      6.1u3       CC:
                                                                        [_] ernst
                                                                        [_] Remove selected CCs
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    roland (roland)
      QA Contact:     roland
          URL:
       * Summary:     sge_qquota not processed properly
   Status whiteboard:
      Attachments:

     Issue 2482 blocks:
   Votes for issue 2482:


   Opened: Mon Feb 4 15:28:00 -0700 2008 
------------------------


Parameters in ~/.sge_qquota or system-wide sge_qquota file are not processed
properly, qquota command seems to ignore the first word in the file.

If ~/.sge_qquota contains "-u *", running qquota generates the following
error: 'error: ERROR! invalid option argument "*"'.

If ~/.sge_qquota is empty, running qquota generates the following
error: 'error: ERROR! invalid option argument "pwf"'.

   ------- Additional comments from clarinet Tue Feb 5 03:13:29 -0700 2008 -------
Is not there a problem on line 470 of qquota.c file? Using "++argv" seems fine
for real command line arguments but may fail when processing arguments read
from a file (where there is no argv[0]).

Also, I am not sure if qquota processes duplicate arguments (those that appear
in a file as well as on a command line) correctly.

   ------- Additional comments from andreas Tue Feb 5 03:52:52 -0700 2008 -------
The

   rp = ++argv;

looks strange at all events. With

   rp = argv++;

the code in sge_parse_cmdline_qquota() makes more sense.

Thanks for reporting!
#492 fixed IZ2507: "root" should be able to submit jobs for arbitrary users via DRMAA Dave Love <d.love@…> andreas
Description

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

   Issue #: 2507   Platform: All   Reporter: andreas (andreas)
   Component: gridengine   OS: All
   Subcomponent: drmaa   Version: 6.1u3   CC:
   [_] james
   [_] Remove selected CCs
   Status: STARTED   Priority: P3
   Resolution:   Issue type: ENHANCEMENT
     Target milestone: Maintrunk
   Assigned to: templedf (templedf)
   QA Contact: templedf
   URL: http://gridengine.sunsource.net/servlets/BrowseList?list=dev&by=thread&from=28404
   * Summary: "root" should be able to submit jobs for arbitrary users via DRMAA
   Status whiteboard:
   Attachments:
   Date/filename:                                     Description:                                                               Submitted by:
   Thu Feb 28 16:15:00 -0700 2008: 2507.diff          Patch to implement "drmaa_submit_as_euid" based on V61_BRANCH (text/plain) andreas
   Mon May 5 05:06:00 -0700 2008: Maintrunk_2507.diff Source diff against maintrunk (RD-2008-05-05-1) (text/plain)               andreas
   Mon May 5 06:17:00 -0700 2008: MT_man2507.diff     Man page diff against Maintrunk for drmaa_attributes(3) (text/plain)       andreas
     Issue 2507 blocks:
   Votes for issue 2507:

   Opened: Thu Feb 28 16:11:00 -0700 2008 
------------------------


DESCRIPTION:
"root" should be able to submit jobs for arbitrary users via DRMAA

HOWTOFIX:
Add a "drmaa_submit_as_euid" job template attribute, that causes effective
user/group be used when drmaa_run_job()/drmaa_run_bulk_job() is being called.

   ------- Additional comments from andreas Thu Feb 28 16:15:52 -0700 2008 -------
Created an attachment (id=155)
Patch to implement "drmaa_submit_as_euid" based on V61_BRANCH

   ------- Additional comments from andreas Fri Apr 25 05:44:10 -0700 2008 -------
According a short report I received from James Vanns he tried the attached patch
and it did work.

   ------- Additional comments from andreas Mon May 5 04:33:26 -0700 2008 -------
Changed IZ-URL so that the mail thread where Dan, James, and I discussed
implementation topics can easily be accessed by anyone.

In informal discussion a number of concernes were raised against this RFE. As to
give anyone a chance to participate in the debate I summarize those amongst the
concerns that I consider as valid:

(1) How can we sure this RFE introduces no new risks in terms of security?
(2) Will this RFE work also in CSP-security mode?

   ------- Additional comments from andreas Mon May 5 05:06:20 -0700 2008 -------
Created an attachment (id=169)
Source diff against maintrunk (RD-2008-05-05-1)

   ------- Additional comments from andreas Mon May 5 06:17:39 -0700 2008 -------
Created an attachment (id=170)
Man page diff against Maintrunk for drmaa_attributes(3)

   ------- Additional comments from roland Mon May 5 06:46:25 -0700 2008 -------
I did a quick review on the patch and as it's implemented it will not work with
SGE's CSP mode. In CSP mode on qmaster side the username provided by the
certificate and the username saved in the GDI session is compared and must be
identical. This check will fail if the context was created with the certificates
of user X and the GDI request claim to come from user Y.

   ------- Additional comments from andreas Mon May 5 07:55:12 -0700 2008 -------
Specificatioon document draft now available under

http://wiki.gridengine.info/wiki/index.php/Submission_for_arbitrary_jobs_via_DRMAA

   ------- Additional comments from andreas Tue May 6 06:01:48 -0700 2008 -------
Having investigated the certificate handling in qmaster I must confirm Rolands
comments. After consultation with Andre I see three possibilities to deal with
that issue:

(1) Enhance the handling of GDI session certificates in a way that one can allow
special rights be consigned from the GDI session owner to the user in whose
procuration the GDI request was sent to qmaster. Imagination is this would
require a general enhancement of SGE certificate schema. Yet as of now there is
no real conception how this schema enhancement had to look like and it is
therefore unclear whether it could be accordingly implemented at all.

(2) Do a small code modification in qmaster where GDI session user and GDI
request user matching ist done (i.e. sge_security_verify_user() and/or
sge_security_verify_unique_identifier()) in a way that procuration is generally
allowed, but only if the GDI session user could be verified as "root" through a
 certificate at the time when the GDI session was opened.

(3) Accept the patch as it is and therefore mention in the release notes and the
drmaa_attributes(3) man page, that "drmaa_submit_as_euid" does not function as
of now. In addition a bug would be filed against "drmaa_submit_as_euid" to make
sure this feature gap is not forgotten.

In my opinion all three options could be justified.

   ------- Additional comments from andreas Thu May 8 09:00:02 -0700 2008 -------
Defered to a 6.2 follow-up version.

Had needed more closer cooperation amongst different stakeholders for getting it
into 6.2 beta.
#508 fixed IZ2553: /tmp/*_messages files are subject to symlink vulnerabilities Dave Love <d.love@…> brooks
Description

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

        Issue #:      2553             Platform:     All       Reporter: brooks (brooks)
       Component:     gridengine          OS:        All
     Subcomponent:    execution        Version:      current      CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    pollinger (pollinger)
      QA Contact:     pollinger
          URL:
       * Summary:     /tmp/*_messages files are subject to symlink vulnerabilities
   Status whiteboard:
      Attachments:

     Issue 2553 blocks:
   Votes for issue 2553:


   Opened: Thu Apr 10 13:48:00 -0700 2008 
------------------------


As far as I can tell, the /tmp/*_messages files deamons use early in startup
are created without the exclusive flag.  As a result, ordinary users can
create symlinks in their place and cause the daemons to write to arbitrary
files.  The files should either be opened exclusivly or the locations should
be changed to a location not writable by ordinary users.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Note: See TracQuery for help on using queries.