Sounds like a novel approach, and seems reasonable on the face of it.
But as a novel security approach, definitely we should bring this up
at ARC.
Lloyd
On Aug 3, 2009, at 5:35 PM, Bill Shannon wrote:
> Currently in v3 the asadmin stop-domain command fails if the domain
> has a non-default admin user and you don't specify the user name.
> In v2 stop-domain would succeed in this case, as long as you were
> on the same machine as the DAS.
>
> The v3 stop-domain command needs to execute the command on the server
> (as opposed to using "kill" or something like that), which means it
> needs to authenticate with the server. To allow v3 to be more
> compatible
> with v2, we're considering adding a new authentication mechanism that
> will "only" work in the local case.
>
> Roughly, here's how this would work...
>
> On server startup, the server would generate a large random number
> and write it in a file that is readable only by the owner of the
> file (the user who started the server).
>
> Local commands, such as stop-domain, would read this file if it's
> available and send the number as part of the authentication
> information
> to the server. The server would accept either the normal username/
> password
> authentication, or some special username along with this number as the
> password.
>
> This allows anyone who can read the file to authenticate to the
> server.
> Normally this would only be the user who owns the server and is
> running
> on the same machine.
>
> First, see any holes with this approach?
>
> Second, should we generalize this approach and allow it to be used
> for normally remote commands as well? This means you could create a
> domain with a non-default admin user and in the local case you would
> never need to specify the admin user name or password, and yet there
> would be some protection against remote admin access.
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team