Bug 1557883

Pushed to `DOGTAG_10_5_BRANCH`:

- c4904a4e39b2dd7ee6064ce04488aca36e19342d console: prohibit empty ACL expression                 
- 021ebec5d54a85d8de56478fb4762c4b15ee0a3a DirAclAuthz.updateACLs: re-throw ACL exception         
- 682fcf270f6b49ff5a6e7133f022982445a74422 ACLEntry.java: return null on parse error              
- 5e36d86d2c5ab2264768e64fe8029e428ce01b92 ACL.java: remove setDescription method                 
- 414a6a63d4833cfe0e575a682378fb9515ad59a6 ACL.java: retain all resourceACLs strings when merging 
- fcacf3d579a2562b764e0caed2cab81d73aa053f ACL.java: Make constructor private and add sanity check
- 8748541f70e1c753589b37f76331a7cadc684253 ACL.java: Remove unused constructor                    
- 80577d3480c8f5aa917db86f962b8acf6f750c55 Move parseACL to ACL.java

add doc text

Test Env:
=======

rpm -qa pki-*
pki-server-10.5.1-11.el7.noarch
pki-core-debuginfo-10.5.1-10.el7.x86_64
pki-base-10.5.1-11.el7.noarch
pki-tests-pki-tests-20150522165149.1561420-0.noarch
pki-javadoc-10.5.1-10.el7.noarch
pki-tps-10.5.1-10.el7pki.x86_64
pki-base-java-10.5.1-11.el7.noarch
pki-ca-10.5.1-11.el7.noarch
pki-tests-pki-tests-dogtag-20151005152014.66e7821-0.noarch
pki-ocsp-10.5.1-10.el7pki.noarch
pki-tools-10.5.1-11.el7.x86_64
pki-tests-CoreOS-dogtag-aakkiang-test-rhcs-1.0.8.20170618003302-0.noarch
pki-symkey-10.5.1-10.el7.x86_64
pki-tks-10.5.1-10.el7pki.noarch
pki-tests-CoreOS-dogtag-PKI_TEST_USER_ID-bbhavsar-1.0.8.RPM.IDENTIFIER-0.noarch
pki-console-10.5.1-5.el7pki.noarch
pki-kra-10.5.1-11.el7.noarch


Test case:
========

1. open pkiconsole
2. Goto ACL on left panel.Add a testACL.
3. Add resourcename=testACL, allowable rights=read,approve
ACL entried add -- allow(read,approve)
write description.
4. Click on "OK".
5. System logs shows:

0.http-bio-20443-exec-3 - [11/Apr/2018:16:16:00 IDT] [13] [3] updateACLs: failed to flushResourceACLs(): Failed to parse ACLs
0.http-bio-20443-exec-3 - [11/Apr/2018:16:16:00 IDT] [10] [3] ACLAdminServlet: Failed to parse ACLs
0.http-bio-20443-exec-3 - [11/Apr/2018:16:16:57 IDT] [13] [3] updateACLs: failed to flushResourceACLs(): Failed to parse ACLs
0.http-bio-20443-exec-3 - [11/Apr/2018:16:16:57 IDT] [10] [3] ACLAdminServlet: Failed to parse ACLs

So ACL's are not getting updated from console and it failed.Exception message is changed now.

Geetika, thanks for testing. 
Can you please explain exactly what you are putting in each ACL field?

- For the ACL entry, which rights are selected in the "Rights" list
- For the ACL entry, the exact contexts of the "Syntax" text field
- For the ACL, the exact contents of the "Allowable rights" field
- For the ACL, the exact contents of the "Description" field.

Created attachment 1420762 [details]
ACL-console log

Hi Fraser, I have attached the screenshot.I think it should help.

Geetika, thanks for the screenshot.

It seems that the ACL entry "Syntax" field was left empty.
I cannot reproduce this with pki-console-10.5.1-5.el7pki.noarch.
In fact, the patch is designed to disallow this; it should cause
and "Incorrect syntax" error dialog after clicking "OK" in the
ACL entry dialog, when then "Syntax" field has been left empty.

See screenshot.

Are you running pki-console-10.5.1-5.el7pki.noarch on the *client* system?
I have tried with this package and the behaviour is as expected (i.e.
what I just described).

Created attachment 1421153 [details]
Screenshot of ACI with empty "Syntax" field resulting in "Incorrect syntax" warning

Thanks Fraser for looking into this.
Yes with pki-console-10.5.1-5.el7pki.noarch it works.
I was trying with a different client(version was little old) as it was HSM.
Now i tried with a non HSM instance and it worked .


Test case 1: Try to add ACL with allow first
------------

AAAAA:read,write:allow (read,write) group="Administrators":testing


Test case 2: Try to add ACL with deny first
------------

abbbb:read,write:deny (read,write) group="Administrators":dfsfsfsfs


Test case 3: Try to add ACL with empty syntax/incorrect syntax
-----------
syntax exception comes which is as expected.

Hi Geetika,

The testing you've performed is sufficient.  In fact, it was still
useful to test with the old client to show that the
StringIndexOutOfBoundsException is now avoided on the server side.
And testing with the new client shows that the invalid data can no longer
be sent to the server.

So this is verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:1979