Bugzilla – Bug 5373
pkg commands shouldn't traceback when client can't read a key/cert file
Last modified: 2009-03-09 14:26:45 UTC
You need to log in before you can comment on or make changes to this bug.
If an authority has a key and certificate associated with it that pkg is unable to read because of permissions, it should not traceback. $ pfexec pkg refresh Traceback (most recent call last): File "/export/home/bpytlik/IPS/gate/proto/root_i386/usr/bin/pkg", line 2228, in ? __ret = main_func() File "/export/home/bpytlik/IPS/gate/proto/root_i386/usr/bin/pkg", line 2171, in main_func return catalog_refresh(mydir, pargs) File "/export/home/bpytlik/IPS/gate/proto/root_i386/usr/bin/pkg", line 1494, in catalog_refresh api_inst.refresh(full_refresh, pargs) File "/usr/lib/python2.4/vendor-packages/pkg/client/api.py", line 551, in refresh if not self.img.check_cert_validity(): File "/usr/lib/python2.4/vendor-packages/pkg/client/image.py", line 511, in check_cert_validity cert = self.build_cert(ssl_cert) File "/usr/lib/python2.4/vendor-packages/pkg/client/image.py", line 490, in build_cert cf = file(path, "rb") IOError: [Errno 13] Permission denied: '/home/bpytlik/Desktop/OpenSolaris_extras.certificate.pem' pkg: This is an internal error. Please let the developers know about this problem by filing a bug at http://defect.opensolaris.org and including the above traceback and this message. The version of pkg(5) is '5a2dfb8ab146'.
See also bug 5408.
Whoever ends up fixing this bug should make sure to verify that they've fixed the traceback in both the pkg refresh case, as well as cases where pkg refresh is implicitly called. In all cases we should return a helpful error message, so that the user knows to either adjust permissions on their key, or invoke pkg as another user. It gets particularly confusing with set-authority -c <cert> -k <key>, because a failure can occur during refresh. In that case we should make sure to print the permissions error, even if the situation is a bit confusing. The bug that deals with cert validation is bug 5060. That bug should address the problem where we add a cert that isn't valid.
Also see bug #5783
My changes for bug 5871 may have resolved this; need to verify.
I made lots of fixes to certs, but I missed this case and shouldn't have in my changes for 5871. I'll go ahead and add this because I consider it a bug that I didn't handle it correctly.
Well, this also has to handle the case where the cert used to be valid (or was at the time of set-publisher) but now is invalid.
*** Bug 5408 has been marked as a duplicate of this bug. ***
Fixed in changeset 926 / 6ee411c9026af426a657cb1f5e4b73c14c2e1112.
*** Bug 7601 has been marked as a duplicate of this bug. ***
*** Bug 5783 has been marked as a duplicate of this bug. ***