classpath
[Top][All Lists]
Advanced

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

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


From: Dalibor Topic
Subject: Re: [Bug classpath/25202] javax.security.auth.login.LoginException: no configured modules for
Date: Sat, 14 Jan 2006 16:27:07 -0800
User-agent: Mutt/1.3.28i

On Sat, Jan 14, 2006 at 10:29:31PM -0000, 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:
> >> 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.

Indeed. We write our down docs, just like we write our own code: the 
licenses for Sun source code and for Sun's documentation do not allow 
reuse, so copying them is out of question for this project. Please
remove such documentation, since it is not free to share, learn from,
modify, and redistribute, and describe the behaviour of the code in
your own words.

One can write much better free documentation than the specs usually, 
anyway, they are hardly worth copying and getting into legal troubles
for.

cheers,
dalibor topic

> 
> >>   - 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
> 
> 
> 
> _______________________________________________
> Bug-classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-classpath




reply via email to

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