Description of problem: If /usr/local happens to be a symbolic link, mandb then attempts to create {CACHEDIR.TAG,cat{0,1,2,3,4,5,6,7,8,9},index.db} in /usr/local/share/man, which are not created else (such files and directories are usually created in /var/cache/man, but not /usr/local/share/man). Manually changing security context of those files and directories to mandb_cache_t (instead of the incorrect man_t context) does not solve the issue, since those files are then deleted and recreated by mandb. SELinux should take into consideration this case, or mandb be fixed if this behavior is a bug. BTW, creating /usr/local/share/man/CACHEDIR.TAG is a bug since /usr/local/share/man is definitively not a cache directory. SELinux is preventing /usr/bin/mandb from 'write' accesses on the file index.db. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that mandb should be allowed write access on the index.db file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep mandb /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:mandb_t:s0-s0:c0.c1023 Target Context system_u:object_r:man_t:s0 Target Objects index.db [ file ] Source mandb Source Path /usr/bin/mandb Port <Unknown> Host (removed) Source RPM Packages man-db-2.6.3-2.fc18.x86_64 Target RPM Packages Policy RPM selinux-policy-3.11.1-106.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.11.9-100.fc18.x86_64 #1 SMP Wed Nov 20 21:22:39 UTC 2013 x86_64 x86_64 Alert Count 4 First Seen 2013-12-12 03:31:06 CET Last Seen 2013-12-16 03:33:05 CET Local ID 7c5a1a1c-1d10-4a78-a50e-5462dd194e55 Raw Audit Messages type=AVC msg=audit(1387161185.65:13021): avc: denied { write } for pid=2065 comm="mandb" name="index.db" dev="dm-3" ino=9043999 scontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:man_t:s0 tclass=file type=SYSCALL msg=audit(1387161185.65:13021): arch=x86_64 syscall=open success=yes exit=ESRCH a0=dfd6f0 a1=2 a2=0 a3=24 items=0 ppid=2060 pid=2065 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=1747 tty=(none) comm=mandb exe=/usr/bin/mandb subj=system_u:system_r:mandb_t:s0-s0:c0.c1023 key=(null) Hash: mandb,mandb_t,man_t,file,write audit2allow #============= mandb_t ============== allow mandb_t man_t:file write; audit2allow -R require { type mandb_t; } #============= mandb_t ============== miscfiles_manage_man_pages(mandb_t) Additional info: reporter: libreport-2.1.9 hashmarkername: setroubleshoot kernel: 3.11.9-100.fc18.x86_64 type: libreport
Should mandb be changed to create the content in the /var/cache directory?
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Seb, this is correct (and configurable) behaviour. If catpath for the manpath is not defined in the /etc/man_db.conf file (see comment starting on line 42) it defaults to the manpath. I'm not sure how to handle this on selinux side, however, I don't see any selinux issues in my environment when I reproduce this scenario. Also, thanks for the CACHEDIR.TAG, it definitely should not be there. peter
Creation of CACHEDIR.TAG should be fixed by now in upstream [1]. And for the original issue reported in this bug, I would propose a following solution: add configurable option DEFAULT_CATPATH to the /etc/man_db.conf file. If catpath for the current manpath is not defined, DEFAULT_CATPATH would be used. If DEFAULT_CATPATH is also not defined, manpath would be used, as it's now. DEFAULT_CATPATH could be set to /var/cache/man (for example). Colin, what do you think about this proposal? We need to limit the possibilities of man-db to create files randomly on the file system. Thanks, peter [1] http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=571ee4f5be8d46d1478cebdfa41d4ef88922a2f4
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Having more symlinks for /usr/share /usr/local and others and setting DEFAULT_CATPATH to /var/cache/man will cause all those symlinked hiearchies to rewrite each other's data. Let's have for example: /usr/share ~> /path/hiearchy1/ /usr/local ~> /path/hiearchy2/ ... Using the DEFAULT_CATPATH will cause for example hiearchy1/man/en/index.db and hiearchy1/man/en/index.db to coincide into /var/cache/man/en/index.db. For the caching of hiearchy1, database variable is set to DEFAULT_CATPATH/PID. We get to the point of calling testmandirs with create variable set to 1. So we create a new database. After leaving create_db, we leave mandb. finish_up is called after (if !opt_test && amount condition is true). This is the hiearchy1 case. Next, caching of hiearchy2 begins. Now, database variable is set to the same name as hiearchy1, i.e. DEFAULT_CATPATH/PID. The process repeats. After succesfull run we end up before finish_up call. It contains this line: xrename (xtmpfile, xfile); It causes the cached db of hiearchy1 being removed and replaced by hiearchy2's db. Conclusions: having common DEFAULT_CATPATH for all nonexisting mappings is not enough. Something like catpath=DEFAULT_CATPATH/hash/manpath/ would be better. Besides, no two hiearchies can collapse, otherwise we would lost information about membership of manpage into hiearchy (We will know the page exists, even its ultimate location. However, what hiearchy the page was from?). hash is needed in a case manpath = /en/cat2 for example (dummy but possible). It would be great to have separate hiearchies (even if those using DEFAULT_CATPATH will be in /var/cache/man/. Or to create a new directory /var/cache/manh/ What do you think Colin?
You're quite right that we can't just collapse all the cat directories on top of each other; there needs to be a one-to-one correspondence between manpaths and catpaths. But this sounds like a huge amount of unnecessary complexity, and man-db's cache creation is hardly random anyway; there's a pretty short list of system hierarchies involved. As the comments in the default configuration file state, above the block of MANDB_MAP directives: "Also, mandb will not initialise the database cache for any manpaths not mentioned below unless explicitly requested to do so." So, I think this line of questioning is entirely missing the point. In the default configuration, which Fedora uses, there should be no reason for the catpath to ever be outside /var/cache/man/ and no reason for it to cause a problem for your SELinux policy. I think the problem is simply that we're taking the list of manpaths to scan from the list of MANDB_MAP directives, but when one of them is a symlink (as is the case here, from the initial bug description) then we canonicalise it before looking up its catpath. This is obviously a bug, and I'll deal with that upstream.
Fixed upstream now: http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=09fa9faab70ed2f4c4c04cc1ad18a8aeac9b8e66
master: https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140915/1382452.html f21: https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140915/1382466.html f20: https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140915/1382490.html f19: https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140915/1382577.html
Thanks Colin.
man-db-2.6.3-8.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/man-db-2.6.3-8.fc19
man-db-2.6.5-5.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/man-db-2.6.5-5.fc20
man-db-2.6.7.1-7.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/man-db-2.6.7.1-7.fc21
Thanks. In future could you please credit the original author of patches when cherry-picking them into Fedora? Removing my name is bad practice.
Package man-db-2.6.5-5.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing man-db-2.6.5-5.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-11076/man-db-2.6.5-5.fc20 then log in and leave karma (feedback).
man-db-2.6.5-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
man-db-2.6.7.1-7.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
man-db-2.6.3-8.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.