I'm finally getting back to this thread.
On Jun 23, 2010, at 6:51 PM, Bill Shannon wrote:
> Tim Quinn wrote on 06/23/10 01:50 PM:
>> Hi.
>>
>> In GlassFish 2 the start-instance command accepts authentication (--
>> user
>> and --passwordfile).
>
> Because it's a remote command, not a local command. Same in v3.
Yes, a command in either version accepts auth. if and only if it's a
remote command. I guess my concern really comes down to labeling the
v3 start-instance it as a local command vs. a remote one. Here's why.
Our plan for DAS-to-instance security relies on the DAS and the server
using mutual certificate-based authentication. What looks to the user
like the single operation of the initial start-up of an instance
actually will involve several internal steps:
1. The process and VM are started.
2. The instance and the DAS exchange security information which they
will use in later connections for mutual authentication.
3. The instance syncs with the DAS to get the application bits it
needs to load and run.
As part of internal step 2, the instance and the DAS will exchange
public keys with each other (no problem there). At the same time, the
DAS will need to send to the instance the private key which the
instance should use in later mutual authentication with the DAS. This
private key is much more sensitive than the the public keys and
GlassFish needs to be careful where it sends that information.
So, in this sense at least, the initial instance start-up resembles a
remote command in that it needs to interact with the DAS.
I think as part of this initial start-up we want two things to happen:
1. The DAS will make sure that the person starting the initial
instance is a legitimate admin user.
2. The user doing the initial instance start-up should be able to see
the self-signed certificate offered by the DAS before going ahead with
the operation.
These are both characteristics of commands we call "remote." Among
other things, I think we'd want to allow the user to specify a
username and password file on the start-instance command line. But
every subsequent start-up of that instance indeed needs to behave as a
local command; we don't want (and won't need) the DAS to be up in
order for the instance to start after its initial start-up.
As long as we understand - and document clearly - that there is this
first-time-only processing that DOES require authentication with the
DAS then, sure, we can call start-instance a local command.
Another option, which I mentioned earlier in the thread, is to rely
solely on file system protections to prevent unauthorized users from
starting an instance. It seems OK to rely on file access permissions
to control who can start a previously-started instance.
I think we want to rely on more than just file permissions to control
who can do that initial start-up of an instance which we know must
include contact with the DAS to succeed -- it should rely on the same
kind authentication to the DAS that other "remote" operations require.
- Tim
>> In GlassFish 3 the start-local-instance command does not accept
>> auth, so
>> presumably any user with access to the GlassFish installation files
>> could start a local instance.
>>
>> Of course, in GlassFish 3 (currently at least) the only thing to
>> authenticate with is the DAS, and we don't want to have to contact
>> the
>> DAS to start an instance because the DAS might not be up. So in
>> GlassFish 3 we rely only on the access controls in the file system to
>> prevent rogue instance starts?
>
> Right. Just like v2, I believe. In v2 I think you could manually
> start
> a server instance using a local command.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>