I'm not sure I followed the discussion below...
start-instance is a remote command. It's a way for an administrator to
(from anywhere) ask the DAS to please start a particular instance. The
DAS uses SSH or (eventually) contacts the node agent on the machine
where the instance will run to start the instance. Obviously the user
needs to authenticate with the DAS.
start-local-instance is a local command. No authentication is required
beyond the operating system permissions to access the files necessary to
start the server.
create-local-instance saves all the authentication information necessary
for start-local-instance to authenticate itself with the DAS based only
on the contents of local files, without requiring the user to provide
additional authentication information. Or at least it should, I don't
know if it currently does.
Did you think it should work differently?
Tim Quinn wrote on 07/05/2010 09:36 PM:
> 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
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>