Bug 990631
Summary: | file permissions of pkcs11.txt/secmod.db must be kept when modified by NSS | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Kai Engert (:kaie) (inactive account) <kengert> | ||||
Component: | nss-util | Assignee: | Elio Maldonado Batiz <emaldona> | ||||
Status: | CLOSED ERRATA | QA Contact: | Hubert Kario <hkario> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | urgent | ||||||
Version: | 6.5 | CC: | djasa, emaldona, hkario, kengert, ksrot, mcrha, rrelyea, sforsber, tlavigne | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | nss-util-3.15.1-3.el6 | Doc Type: | Bug Fix | ||||
Doc Text: |
Cause: NSS changed the permissions of the existing pkcs11.txt file, reverting to the strict default of 0600, even when the file previously had other permissions.
Consequence: This prevented users from adding security modules to their own configuration which is accomplished via acces to the system-wide security databses. If the user has root access the system database is modified otherwise the user's own default database is the one that is modified.
Fix: NSS now keeps the strict default 0600 permissions for new files while preserving the existing permissions when replacing an existing pkcs11.txt file.
Result: Users can now make the necessary modifications to the nss security module database.
|
Story Points: | --- | ||||
Clone Of: | |||||||
: | 1087926 (view as bug list) | Environment: | |||||
Last Closed: | 2013-11-21 06:16:41 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 993793, 1002222, 1087926 | ||||||
Attachments: |
|
Description
Kai Engert (:kaie) (inactive account)
2013-07-31 15:25:43 UTC
There is third issue with modutil (and it's other *util siblings probably as well): when no -dbdir is specified, it assumes old /etc/pki/nssdb instead of now-preferred shareable sql:/etc/pki/nssdb. WRT (1) part of the description: $ sudo strace modutil -dbdir sql:/etc/pki/nssdb/ -add "CoolKey PKCS#11 Module" -libfile /usr/lib64/pkcs11/libcoolkeypk11.so 2>&1 | grep pkcs11.txt open("/etc/pki/nssdb/pkcs11.txt", O_RDONLY) = 3 open("/etc/pki/nssdb/pkcs11.txt", O_RDONLY) = 14 open("/etc/pki/nssdb/pkcs11.txt", O_RDWR|O_CREAT|O_APPEND, 0600) = 14 open("/etc/pki/nssdb/pkcs11.txt", O_RDONLY) = 14 unlink("/etc/pki/nssdb/pkcs11.txt") = 0 access("/etc/pki/nssdb/pkcs11.txt", F_OK) = -1 ENOENT (No such file or directory) rename("/etc/pki/nssdb/pkcs11.txu", "/etc/pki/nssdb/pkcs11.txt") = 0 open("/etc/pki/nssdb/pkcs11.txt", O_RDONLY) = 14 open("/etc/pki/nssdb/pkcs11.txt", O_RDWR|O_CREAT|O_APPEND, 0600) = 14 $ sudo strace -f nss-gui 2>&1 | grep pkcs11.txt [pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDONLY) = 3 [pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDONLY) = 39 [pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDWR|O_CREAT|O_APPEND, 0600) = 39 [pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDONLY) = 39 [pid 10185] unlink("/etc/pki/nssdb//pkcs11.txt") = 0 [pid 10185] access("/etc/pki/nssdb//pkcs11.txt", F_OK) = -1 ENOENT (No such file or directory) [pid 10185] rename("/etc/pki/nssdb//pkcs11.txu", "/etc/pki/nssdb//pkcs11.txt") = 0 [pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDONLY) = 39 [pid 10185] open("/etc/pki/nssdb//pkcs11.txt", O_RDWR|O_CREAT|O_APPEND, 0600) = 39 In nss.spec the relevant lines are: Source8: system-pkcs11.txt ### line below renames it %{__install} -p -m 644 %{SOURCE8} $RPM_BUILD_ROOT/%{_sysconfdir}/pki/nssdb/pkcs11.txt ^^^ --- read access for everyone %config(noreplace) %verify(not md5 size mtime) %{_sysconfdir}/pki/nssdb/pkcs11.txt They are the same as they were on rhel-6.4. Something else is going on outside of the nss.spec. I'am looking at in fedoara, will be doing it my rhel-6.5 VM but I am seeing even in f19 the wrong persmisions. Using modutil I can add the coolkey module only via sudo. When I try it as mysef it fails with "modutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format." It doesn't make sense because I invoked the tool via modutil -dbdir sql:/etc/pki/nssdb/ \ -add "CoolKey PKCS#11 Module" -libfile /usr/lib64/pkcs11/libcoolkeypk11.so I explicitly used the sql: prefix. I bet modutil isn't aware of prefixes. Perhaps it should be. That still doesn't explain the wrong permissions which is the main subject of this bug. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=900067 upstream for the file permissions on pkcs11.txt Elio, I think your comment 3 might be irrelevant for this bug. Yes, we agree the permissions are initially right, it's about permissions being changed by modutil. Second, the modutil tool works correctly when using the sql: prefix. Of course you require sudo to change the files in /etc. Of course you'll get an error if you try to change /etc/ with your regular user account. The error message you saw is simply an incorrect error message, as modutil doesn't expect to lacking permissions for the files given. I filed upstream bug 900086 for the cosmetic issue regarding the warning printed by modutil. It isn't blocking this work, it's just nice to have. (In reply to David Jaša from comment #1) > There is third issue with modutil (and it's other *util siblings probably as > well): when no -dbdir is specified, it assumes old /etc/pki/nssdb instead of > now-preferred shareable sql:/etc/pki/nssdb. We can't change the behaviour of the tools in a RHEL branch. Even though shared sql might now be prefered, there are still applications that use it, e.g. Firefox. Until we can make the new access method the default in most applications, it might be good to keep the old default, to minimize confusion. If we're ever going to make a change, it might be wise to require the user to explicitly specifc the access mechanism, but that also has problems because of script automation etc. Anyway, I think that's not easily doable and is a separate discussion. So we have a whole host of issues in one bug, and that makes things confusing. Some of these issues are upstream issues, others are probably local. Let me address them one at a time...
1) Permissions: In RHEL and fedora, we should always seed /etc/pki/nssdb from the spec file with an appropriate pkcs11.txt. When NSS is automatically creating the file (which means softokn in this case. modutil isn't actually doing the open), it doesn't know whether the file is a shared (among users) file or not. The correct default is 0600 for creation of this file. example:
mkdir test
certutil -N -d test
ls -l
So this isn't a bug in modutil. We need to make sure when we put the initial seeded versions for the system files in /etc/pki/nssdb, that they have to correct permissions (which I think Elio has shown). If there are some instructions for recreating them, then we need to add the chmod a+r to those instructions..
--------------------------------------------------------------------------
2) modutil's warning. This is an upstream issue. We probably should only warn if we are using dbm. I don't consider this a serious or high priority. It actually won't be really easy to fix (the underlying details of the token are usually pretty hidden from the application. Looking at the string is not a reliable way of fixing this, someday NSS may change the default to always be sql).
---------------------------------------------------------------------------
3) modutil/certutil default. I thought the default was ~/netscape, or something. I'm OK with changing it to sql:/etc/pki/nssdb upstream, but that discussion needs to happen there. What ever happens upstream, certainly changing this default for fedora/RHEL-7 is probably a good idea.
--------------------------------------------------------------------------
> Second, the modutil tool works correctly when using the sql: prefix. Of
> course you require sudo to change the files in /etc. Of course you'll get
> an error if you try to change /etc/ with your regular user account. The
> error message you saw is simply an incorrect error message, as
> modutil doesn't expect to lacking permissions for the files given.
I'm curious if you did this experiment with nsssysinit turn on. If you did, modutil should modify the users pkcs11.txt (~/.pki/nssdb I think) just like certutil does for the .db's.
bob
> Even though shared sql might now be prefered, there are still applications
> that use it, e.g. Firefox.
To be clear, I think the default David is talking about is the default for the NSS tools if no database is supplied, not what NSS opens by default if the sql: or dbm: isn't included.
In any case I agree we have to be careful about changing defaults for the tools on shipping versions of RHEL. Kai's instincts are exactly correct.....
....OTOH I doubt very seriously that there is anyone using the defaults. On RHEL-6 certutil -L does not list /etc/pki/nssdb (either dbm: or sql: ). The current default is actually ~/.netscape... still probably not a RHEL 6.5 change we should make without floating out a trail balloon or something...
--------------------------------
(BTW you can change 'whether to open dbm: or sql:' default with an environment variable. I've been running with the NSS_DEFAULT_DB_TYPE=sql for 5 years now (which actually forces Firefox and Thunderbird to use sql databases rather than dbm, just not the system sql databases)). Still again, Kai's instincts are correct. I don't run with those databases in NFS, so there may be weirdness in some environments. I don't even think we can make this kind of change in fedora or RHEL-7 yet (unfortunately. I'd like to be able to drop dbm support from RHEL-7). Clearly making this change in RHEL 6.5 is out.
There was a misunderstanding that we clarified during a phone call. The problem is that core NSS *changes* the permissions of the existing pkcs11.txt file, *reverting* them back to the default 0600, even if the file previously had other permissions. We agreed on the following during the call: - if pkcs11.txt does not yet exist, we should create it as 0600 - if pkcs11.txt already exists, we must keep the permissions when modifying As of today, our code uses a series of two commands, in order to use the permission flags, but still associate it with a FILE*: - fd = open(name, O_CREAT|O_RDWR|O_TRUNC, 0600); - fdopen(fd, "w+"); It's more complicated even, the existing code in nssutil_DeleteSecmodDB might sometimes erase the old file and create a new one. I conlcude: The correct implementation strategy is to use "stat" to obtain the existing permissions, and using them when creating the new files. I propose to do all further technical discussion related to pkcs11.txt in the upstream bug. Regarding the warnings printed by modutil: Based on the comments I'll remove it from this RHEL bug, but we'll still track it upstream. Created attachment 789005 [details]
The patch Kai has submitted upstream
The patch changes nss/lib/util The patch must be added to the nss-util package - not the nss package. The package of this bug should be changed to nss-util. To avoid this kind of mistake (which has happened in the past), we should consider to "rm -rf nss/lib/util" directory after unpacking the source archive. 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. http://rhn.redhat.com/errata/RHBA-2013-1558.html |