Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 91828 invoked from network); 22 Jun 2007 22:09:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Jun 2007 22:09:08 -0000 Received: (qmail 1122 invoked by uid 500); 22 Jun 2007 22:09:11 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 894 invoked by uid 500); 22 Jun 2007 22:09:11 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 883 invoked by uid 99); 22 Jun 2007 22:09:10 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2007 15:09:10 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of francois.orsini@gmail.com designates 64.233.162.233 as permitted sender) Received: from [64.233.162.233] (HELO nz-out-0506.google.com) (64.233.162.233) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2007 15:09:06 -0700 Received: by nz-out-0506.google.com with SMTP id i11so1089388nzh for ; Fri, 22 Jun 2007 15:08:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=hhPu3bEVVbRY55ptwNbyt/sJN8InGA3XVBCydAJlFNPPNuoIFuWz1MqSdmwA260CUHCIJcr8N8NqxGsexKlqK9vFo4lSYchDred+wqTH7rYOV61zcuYU1+g/MS6p7xd6w0sYC6jQtdki4ocgwQFDEVIOJofioAxyeKGQlcrJM6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HW/zuMQgoV9hFlJOvgI/0K1M34haojwWzn+lvDJOhRuoby2DPi7XDQgr0VAYyCz2r1vyduRe7FFtKrOJauKGl4wRYRa7dRBxrOYpjqt5ORcaT1ilPwGcyhmN61juISf1FdTeXB3O8gmpTpttTREqWcilAD2DAsvc4iGLpih01as= Received: by 10.114.107.19 with SMTP id f19mr3367629wac.1182550124999; Fri, 22 Jun 2007 15:08:44 -0700 (PDT) Received: by 10.114.197.6 with HTTP; Fri, 22 Jun 2007 15:08:44 -0700 (PDT) Message-ID: <7921d3e40706221508k6a5164bdw1e47445e21678cc2@mail.gmail.com> Date: Fri, 22 Jun 2007 15:08:44 -0700 From: "Francois Orsini" To: derby-dev@db.apache.org Subject: Re: NetworkServerControl shutdown w/ authentication failing? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_166596_21160870.1182550124973" References: <4679FC94.1070104@sun.com> <7921d3e40706211555m37bfc588ue1533ddeaea92e78@mail.gmail.com> <56a83cd00706211704i6424e9m865543402e7824f1@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_166596_21160870.1182550124973 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/07, Knut Anders Hatlen wrote: > > David Van Couvering writes: > > > I think "invalid authentication" is incorrect, because actually it > > should be "this user is not authorized to shut down the database." > > The authentication went fine, it's just they aren't authorized. There > > is security and there is being completely misleading. The poor user > > will scratch their heads, like Martin did, wondering what on earth is > > wrong with their user and password, especially when they can log in to > > do other things. > > Since the problem here is that the shutdown command in > NetworkServerControl does not pick up the user name or the password, I > think "invalid authentication" is correct. It tries to shut down the > database using the default user and no password when > derby.connection.requireAuthentication is true, hence it is not > authenticated (whereas the default user may or may not be authorized to > shut down the database). Correct. > On 6/21/07, Francois Orsini wrote: > >> > >> > >> On 6/21/07, Knut Anders Hatlen wrote: > >> > Martin Zaun writes: > > >> > > - For better diagnostics, should the "Invalid authentication" > message > >> > > tell the user name being used for authentication? > >> > >> We could have - this has been there for ages - I think it was done > >> originally for extra security ;-) One does not say anything about what > went > >> wrong with the credentials, one just fails to authenticate and the > requester > >> should know what to do to fix it (no guidance as far as what went wrong > - > >> other databases also do this - I remember having looked at other RDBMS > but > >> it was long ago). > > I don't think adding the user name to the error message would reduce the > security. Sure, "User 'APP' does not exist" or "Invalid password for > user 'APP'" would be problematic, as they would reveal whether or not a > user existed. However, a message like "Invalid authentication for user > 'APP'" would be OK since it doesn't say what went wrong, and it would be > more useful since Martin (or any other user) would immediately see that > the supplied user name had not been picked up. Fair enough for the server (NetworkServerControl) - Yes, in this context it is hard to find out which user has failed to authenticate. +1 -- > Knut Anders > ------=_Part_166596_21160870.1182550124973 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/07, Knut Anders Hatlen <Knut.Hatlen@sun.com> wrote:
David Van Couvering <david@vancouvering.com> writes:

> I think "invalid authentication" is incorrect, because actually it
> should be "this user is not authorized to shut down the database."
> The authentication went fine, it's just they aren't authorized.  There
> is security and there is being completely misleading.  The poor user
> will scratch their heads, like Martin did, wondering what on earth is
> wrong with their user and password, especially when they can log in to
> do other things.

Since the problem here is that the shutdown command in
NetworkServerControl does not pick up the user name or the password, I
think "invalid authentication" is correct. It tries to shut down the
database using the default user and no password when
derby.connection.requireAuthentication is true, hence it is not
authenticated (whereas the default user may or may not be authorized to
shut down the database).

Correct.

> On 6/21/07, Francois Orsini < francois.orsini@gmail.com> wrote:
>>
>>
>> On 6/21/07, Knut Anders Hatlen <Knut.Hatlen@sun.com> wrote:
>> > Martin Zaun <Martin.Zaun@Sun.COM> writes:

>> > > - For better diagnostics, should the "Invalid authentication" message
>> > >   tell the user name being used for authentication?
>>
>> We could have - this has been there for ages -  I think it was done
>> originally for extra security ;-) One does not say anything about what went
>> wrong with the credentials, one just fails to authenticate and the requester
>> should know what to do to fix it (no guidance as far as what went wrong -
>> other databases also do this - I remember having looked at other RDBMS but
>> it was long ago).

I don't think adding the user name to the error message would reduce the
security. Sure, "User 'APP' does not exist" or "Invalid password for
user 'APP'" would be problematic, as they would reveal whether or not a
user existed. However, a message like "Invalid authentication for user
'APP'" would be OK since it doesn't say what went wrong, and it would be
more useful since Martin (or any other user) would immediately see that
the supplied user name had not been picked up.

Fair enough for the server (NetworkServerControl) - Yes, in this context it is hard to find out which user has failed to authenticate. +1

--
Knut Anders

------=_Part_166596_21160870.1182550124973--