bug-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug classpath/25202] javax.security.auth.login.LoginException: no confi


From: csm at gnu dot org
Subject: [Bug classpath/25202] javax.security.auth.login.LoginException: no configured modules for
Date: 14 Jan 2006 22:29:31 -0000


------- 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:
>> This patch looks pretty good; thanks for doing this!
>>
>> I do, however have a couple of comments:
>>
>>   - First, the documentation comments you've added to the
>> Configuration class look very similar to those Sun distributes. Does
>> the license for Sun's API documentation allow you to do this?
>
> i always thought you can; if not should be easy to remove. Mark?
>

We've been having discussions about our usage of IETF RFC text in  
documentation comments, and RFC's have a more free license than I  
imagine Sun's documentation does, and it seems as though *even that*  
is not free enough to include in Classpath.

>>   - 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.

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

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

>>   - The file is called `ConfigFileParser.java' but the opening
>> comment line says it's `ConfigurationParser.java.'
>
> thanks for picking this up.
>
>>   - I think you should consider sending debug statements to a logger,
>> and not to the console. See the package `gnu.classpath.debug' for
>> more info.
>
> i tried amending the Component class but didn't see any output when i
> ran the Mauve tests. i's prefer to use proper debugging than the ad- 
> hoc
> approach of sending to System.out.  is there an example usage
> somewhere?
>

You have to do a couple of things: first, ensure that your logging  
system is configured to print statements at level FINE or greater  
(this includes both the logger instance 'gnu.classpath" and the  
handler class (e.g. ConsoleHandler) is also configured to publish  
records at FINE or greater). Then, you have to enable the precise  
components to log with the `gnu.classpath.debug.components' system  
property.

I usually set up my logging system to log `gnu.classpath' messages to  
a log file, and switch on debug components that I'm interested in. I  
can send you this config file, if you are interested.

Thanks.


-- 


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]