Re: [Monetdb-developers] [Monetdb-checkins] MonetDB5/src/mal mal_authorize.mx, Nov2009, 1.82.4.3, 1.82.4.4
On 03-11-2009 20:16:25 +0000, Martin Kersten wrote:
Update of /cvsroot/monetdb/MonetDB5/src/mal In directory 23jxhf1.ch3.sourceforge.com:/tmp/cvs-serv5258
Modified Files: Tag: Nov2009 mal_authorize.mx Log Message: Test the language argument. Possibly null check. Discovered by Coverity
I think this commit breaks the original logic since the scenario bat may be empty for e.g. the superuser.
Fabian Groffen wrote: there is/should always be a scenario. The default being 'mal'
Index: mal_authorize.mx =================================================================== RCS file: /cvsroot/monetdb/MonetDB5/src/mal/mal_authorize.mx,v retrieving revision 1.82.4.3 retrieving revision 1.82.4.4 diff -u -d -r1.82.4.3 -r1.82.4.4 --- mal_authorize.mx 31 Oct 2009 09:08:59 -0000 1.82.4.3 +++ mal_authorize.mx 3 Nov 2009 20:16:23 -0000 1.82.4.4 @@ -394,16 +394,14 @@ /* now see if the scenario is permitted (if restrictions for that * apply) */ + if (scenario == NULL || *scenario == NULL || strNil(*scenario)) + /* of course we DO NOT tell the exact reason here again */ + throw(INVCRED, "checkCredentials", INVCRED_INVALID_USER " '%s'",*username); + b = BATselect(scen, id, id); if (b && BATcount(b) > 0) { BATiter bi = bat_iterator(b);
- if (*scenario == NULL || strNil(*scenario)) { - BBPunfix(b->batCacheid); - /* of course we DO NOT tell the exact reason here again */ - throw(INVCRED, "checkCredentials", INVCRED_INVALID_USER " '%s'",*username); - } - /* ok, there are some tuples that we have to consider */ BATloop(b, p, q) { tmp = (str)BUNtail(bi, p);
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Monetdb-checkins mailing list Monetdb-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Monetdb-checkins mailing list Monetdb-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
On 03-11-2009 22:22:54 +0100, Martin Kersten wrote:
On 03-11-2009 20:16:25 +0000, Martin Kersten wrote:
Update of /cvsroot/monetdb/MonetDB5/src/mal In directory 23jxhf1.ch3.sourceforge.com:/tmp/cvs-serv5258
Modified Files: Tag: Nov2009 mal_authorize.mx Log Message: Test the language argument. Possibly null check. Discovered by Coverity
I think this commit breaks the original logic since the scenario bat may be empty for e.g. the superuser.
Fabian Groffen wrote: there is/should always be a scenario. The default being 'mal'
IIRC (and I actually checked it, so I DO recall correctly), the contract is: if there is none, you have access to all. This is the default, and for sure for the admin user (monetdb). AFAICT, you introduced a behavioural change which IMHO should go to Current, not the Candidate. PS. milena: Google.
Fabian Groffen wrote:
On 03-11-2009 22:22:54 +0100, Martin Kersten wrote:
On 03-11-2009 20:16:25 +0000, Martin Kersten wrote:
Update of /cvsroot/monetdb/MonetDB5/src/mal In directory 23jxhf1.ch3.sourceforge.com:/tmp/cvs-serv5258
Modified Files: Tag: Nov2009 mal_authorize.mx Log Message: Test the language argument. Possibly null check. Discovered by Coverity I think this commit breaks the original logic since the scenario bat may be empty for e.g. the superuser.
Fabian Groffen wrote: there is/should always be a scenario. The default being 'mal'
IIRC (and I actually checked it, so I DO recall correctly), the contract is: if there is none, you have access to all. This is the default, and for sure for the admin user (monetdb). AFAICT, you introduced a behavioural change which IMHO should go to Current, not the Candidate. ok, look fro another solution satisfying Coverity complaints.
participants (2)
-
Fabian Groffen -
Martin Kersten