Sorry, I forgot to remove "-f" and "-p" options for kinit
http://cr.openjdk.java.net/~asmotrak/8075299/webrev.03/
Artem
On 09/10/2015 03:18 PM, Artem Smotrakov wrote:
Hi Max,
It seems that kinit doesn't print any info about ticket flags [1] (I
am not sure that it is a good idea to rely on
-Dsun.security.krb5.debug=true here). But klist does. I updated the
test to run klist which checks tickets for forwardable and proxiable
flags.
http://cr.openjdk.java.net/~asmotrak/8075299/webrev.02/
[1]
http://docs.oracle.com/javase/8/docs/technotes/tools/windows/kinit.html
Artem
On 09/10/2015 11:48 AM, Wang Weijun wrote:
Everything is fine. Some answers inline:
On Aug 6, 2015, at 9:42 PM, Artem Smotrakov
<[email protected]> wrote:
By the way, as far as I know, currently it is not possible to
specify a port number in "java.security.krb5.kdc”.
Yep.
What do you think?
I have thought about analyzing the strings and treat one as port if
it’s only digits. For example, a:1:b:c means a:1, b and c. a:1:2
looks invalid but accept it for compatibility and treat it as a:1 and
2, at least if a:1 works 2 will not be touched.
The conf file only contains realm and kdc and nothing else. If both
conf file and system properties are provided, how do you prove the
conf file is also read and not ignored?
The test doesn't check it. I see the following ways to check it:
- Corrupt krb5 conf, and run kinit with it. I suppose it should fail.
- Add some extra parameters to krb5, run kinit, and then try to use
obtained data, and check that those extra parameters were used (I am
not sure about details right now, need to do some experiments)
What do you think?
You can add forwardable=true and check if the output is indeed
forwardable. In case it’s default true, try again with
forwardable=false. :-)
Thanks
Max
