[Bug classpath/25202] javax.security.auth.login.LoginException: no configured modules for

[raif at swiftdsl dot com dot au]

------- Comment #8 from raif at swiftdsl dot com dot au  2006-01-14 23:02 
-------
Subject: Re:  javax.security.auth.login.LoginException: no configured modules
for

On Sunday 15 January 2006 09:29, csm at gnu dot org wrote:
> ------- Comment #7 from csm at gnu dot org  2006-01-14 22:29 -------
> Subject: Re:  javax.security.auth.login.LoginException: no configured
> modules for
>
> On Jan 14, 2006, at 1:57 PM, raif at swiftdsl dot com dot au wrote:
> > On Sunday 15 January 2006 08:05, csm at gnu dot org wrote:
> >> ...
> >>   - You can feel free to use the `gnu.classpath.SystemProperties'
> >> class instead of the System class to fetch properties like
> >> `user.home.' This will avoid permission checks for those calls.
> >
> > i thought about that but decided against it for consistency.  the
> > rationale is that there is no point bypassing security checks for
> > system properties when reading security properties, or files may
> > throw one.  ...unless of course all operations do that.
> >
> > does that make sense?
>
> Well, it seems to me that the reading of properties in this case is a
> privileged action, which can succeed no matter who initiates that
> reading -- code that is unprivileged to read all system/security
> properties can call the privileged code, but we don't want *that*
> usage to throw a SecurityException.

i don't think reading system properties should succeed.  it makes more 
sense to me that in order to benefit from, and use, JAAS the code has 
to have a security policy that, at least, allows it to read system 
properties.


> That is, code should be permitted to use JAAS, but NOT permitted to
> read anything sensitive at the same time.

the use of the Configuration (and its subclasses) is itself conditioned 
by security properties; e.g. the refresh() method.  why then would you 
want to respect that restriction on the Configuration itself but bypass 
it in its implementation?


> SystemProperties is just more convenient than using AccessController
> to accomplish this; we will probably add a SecurityProperties class
> that does the same thing.

this only addresses system properties, what about the security 
properties and file reading?  are you implying running (all) the 
Configuration logic as privileged code?


cheers;
rsn


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25202