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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
David Van Couvering <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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 < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
>>
>>
>> On 6/21/07, Knut Anders Hatlen <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
>> > Martin Zaun <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
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
