jdk/test/sun/security/provider/PolicyFile/EmailAddress.java
author lana
Thu, 10 Jun 2010 18:58:31 -0700
changeset 5753 e0ee3917e318
parent 5506 202f599c92aa
permissions -rw-r--r--
Merge

/*
 * Copyright (c) 2002, 2003, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * @test
 * @bug 4702543
 * @summary X500Principal encodes EmailAddress incorrectly -
 *
 *      fix has compatibility ramifications for policy.
 *
 *      this test is related to the Alias.java test in the same directory.
 *      the email address encoding in EmailAddress.policy is the one
 *      taken from the persistent certificate stored in Alias.keystore,
 *      and which has the incorrect encoding.  the alias is 'duke',
 *      and the DN is:  "emailaddress=duke@sun".  the cert was generated
 *      by a 1.4 JDK, so it has the wrong encoding for "duke@sun"
 *      (UTF-8 string instead of IA5String, i believe).
 *
 *      administrators would have placed an incorrectly encoded DN entry
 *      like this in their policies.  the fix for the above bug
 *      would have broken their policy because the incorrect
 *      encoding would be compared to a properly encoded DN from
 *      the current call thread.  if you run this test without
 *      a fix for the compatibility issue, the debug output will
 *      show the differences in the encodings.
 *
 *      so in addition to fixing the encoding,
 *      the policy implementation was updated to read the
 *      incorrectly encoded DN strings, generate new X500Principals,
 *      and dump out new DN strings that had the correct encoding.
 *      thus access control checks would no longer fail.
 *
 * @run main/othervm/policy=EmailAddress.policy -Djava.security.debug=policy EmailAddress
 */

import java.security.*;
import java.util.*;

public class EmailAddress {

    public static void main(String[] args) {

        Principal[] principals = new Principal[1];
        principals[0] = new javax.security.auth.x500.X500Principal
                                        ("emailaddress=duke@sun");

        java.net.URL url = null;
        try {
            url = new java.net.URL("http://emailaddress");
        } catch (java.net.MalformedURLException mue) {
            System.out.println("test 1 failed");
            throw new SecurityException(mue.getMessage());
        }
        CodeSource cs =
            new CodeSource(url, (java.security.cert.Certificate[]) null);

        ProtectionDomain pd = new ProtectionDomain
                (cs,
                null,
                null,
                principals);

        PermissionCollection perms = Policy.getPolicy().getPermissions(pd);

        if (perms.implies(new SecurityPermission("EMAILADDRESS"))) {
            System.out.println("test succeeded");
        } else {
            System.out.println("test 2 failed");
            throw new SecurityException("test failed");
        }
    }
}