db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Zaun <Martin.Z...@Sun.COM>
Subject Re: NetworkServerControl shutdown w/ authentication failing?
Date Tue, 26 Jun 2007 20:56:10 GMT

Thanks for your response so far.  A recap and a few more questions:

1) It's a gap that 'NetworkServerControl shutdown' doesn't pick up/transmit the
    user credentials (as 'NetworkServerControl start' does).  I'm going to open
    a JIRA on this issue for further discussion if there are no objections.

2) The "Derby shutdown warning" seen with 'NetworkServerControl shutdown'
    indicates an authentication issue in the clean shutdown attempt of the
    database -- though, the example I've given didn't even involve a database,
    just a server start and shutdown.  But anyway, the warning is caused by the
    authentication failure with 'NetworkServerControl shutdown' (see 1).

3) To check my understanding: the "Derby shutdown warning" is only a warning,
    and not an error, because the server shutdown can proceed -- at the expense
    of having to run recovery upon next database boot.

4) I wonder if that semantics (print authentication warning but proceed with
    server shutdown) should be kept in place once the authentication issue with
    'NetworkServerControl shutdown' is fixed (and we have System Privileges
    (DERBY-2109) fully integrated).

    In this case, I'd expect, an authentication/permission check failure
    - should be indicated as an exception in the 'NetworkServerControl shutdown'
      command -- and not as a warning in the server process -- and
    - no database/server action whatsoever should be taken in the server since
      the authentication (or system privileges check) has failed.
    Any comments?

5) No final security concerns for the "Invalid authentication" message to tell
    the user name being used for authentication ('APP' in my example).

6) I'd assume that 4) and 5) can be discussed/made part of 1), the JIRA to be
    opened on "'NetworkServerControl shutdown' must transmit user credentials".
    Any comments?

7) By the derby documentation (Reference Manual and Admin Guide)
        http://db.apache.org/derby/docs/dev/ref/rrefattrib16471.html
        http://db.apache.org/derby/docs/dev/adminguide/tadminconfigshuttingdownthenetworkserver.html
    the observed, major difference between the two shutdown methods
    - URL shutdown (connect 'jdbc:derby://localhost:1527/;shutdown=true') shuts
      down the engine but keeps the server process running, while
    - 'NetworkServerControl shutdown' command shuts down the entire server
      process,
    is not quite explicit to me.  Intended behaviour or documentation gap?

Thanks,
Martin


Francois Orsini wrote:
> 
> 
> On 6/22/07, *Knut Anders Hatlen* <Knut.Hatlen@sun.com 
> <mailto:Knut.Hatlen@sun.com>> wrote:
> 
>     David Van Couvering <david@vancouvering.com
>     <mailto: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
>     <mailto:francois.orsini@gmail.com>> wrote:
>      >>
>      >>
>      >> On 6/21/07, Knut Anders Hatlen <Knut.Hatlen@sun.com
>     <mailto:Knut.Hatlen@sun.com>> wrote:
>      >> > Martin Zaun <Martin.Zaun@Sun.COM <mailto: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
> 
> 


Mime
View raw message