Description of problem: fixfiles with lots of output gets garbled? Note: setfile's guts is since re-written / moved into a library, in the upstream version. So what I really need to do is test upstream; I have some prior experience with this. Unfortunately the set of messages has changed too, so what I _really_ need to do is root-cause this and then see if the cause still applies upstream. Version-Release number of selected component (if applicable): policycoreutils-2.5-19.fc25.x86_64 How reproducible: Not yet sure. I have lots of files that selinux doesn't agree with the labelling of, mainly files in my Trash (there's some label change that doesn't happen), and /var/lib/machines - a small Debian install I moved there, but have yet to label. My guess is that's why it gets garbled - that it requires a lot of output to happen. Actual results: $ time sudo fixfiles check ... /sbin/setfiles: Warning no default label for /tmp/.XIM-unix fined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:gkeyringd_tmp_t:s0 /sbin/setfiles reset /run/user/1001/keyring/pkcs11 context unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:gkeyringd_tmp_t:s0 /sbin/setfiles reset /run/user/1001/keyring/control context unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:gkeyringd_tmp_t:s0 real 1m24.504s user 1m18.018s sys 0m4.310s Expected results: Output does not include garbled lines such as "fined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:gkeyringd_tmp_t:s0" Additional info: It's probably not relevant, but the fixfiles command was run inside gnome-terminal. Both normal and maximized windows showed this garbled output at the end.
Patch (with analysis) submitted upstream. https://marc.info/?l=selinux&m=149054550316148&w=2
Ok. Patch has been accepted now. https://marc.info/?l=selinux&m=149073100103838&w=2
Please don't close this bug unless it's fixed in Fedora. We don't expect to update SELinux Userspace to latest release in Fedora 25 as it needs SETools 4 and Fedora 25 is simply not prepared for such a big change. The patches will be backported and used in the next update but we need to know that this issue exists - it's open. POST state means that there's a fix available for an issue.
And I forgot: Thanks for your work! I'll try to prepare an update during this week.
Ok! I'll be more cautious if I see POST used again. Thanks for the explanation.
policycoreutils-2.6-5.fc27 - https://koji.fedoraproject.org/koji/taskinfo?taskID=18820403
policycoreutils-2.6-5.fc26 libselinux-2.6-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f21a1bffda
policycoreutils-2.5-20.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c89d1d37d0
policycoreutils-2.5-20.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-c89d1d37d0
libselinux-2.6-5.fc26, policycoreutils-2.6-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f21a1bffda
Testing note: The backport is expected to fix the specific bug described here. However AFAICT from code review, the output will still be scrambled if you redirect it to a file. The latter bug is fixed upstream, but would have taken longer to backport.
policycoreutils-2.5-20.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
libselinux-2.6-5.fc26, policycoreutils-2.6-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Could this patch have introduced this issue: 22:52:41 localhost audit[282]: AVC avc: denied { write } for pid=282 comm="fixfiles" name="fd" dev="proc" ino=13899 scontext=sys.id:sys.role:seutils.setfiles.subj:s0 tcontext=sys.id:sys.role:seutils.setfiles.subj:s0 tclass=dir permissive=1 Apr 29 22:52:41 localhost audit[282]: AVC avc: denied { add_name } for pid=282 comm="fixfiles" name="1" scontext=sys.id:sys.role:seutils.setfiles.subj:s0 tcontext=sys.id:sys.role:seutils.setfiles.subj:s0 tclass=dir permissive=1 Apr 29 22:52:41 localhost audit[282]: AVC avc: denied { create } for pid=282 comm="fixfiles" name="1" scontext=sys.id:sys.role:seutils.setfiles.subj:s0 tcontext=sys.id:sys.role:seutils.setfiles.subj:s0 tclass=file permissive=1 Apr 29 22:52:41 localhost audit[282]: AVC avc: denied { associate } for pid=282 comm="fixfiles" name="1" scontext=sys.id:sys.role:seutils.setfiles.subj:s0 tcontext=sys.id:sys.role:fs.proc.fs:s0 tclass=filesystem permissive=1 It seems to attempt to create /proc/self/fd/1 ($LOGFILE}, but it should not be doing that
Please open a new issue to avoid cluttering this one. Assuming your issue was introduced by a recent update, the specific change is probably an independent one (not required to fix the garbled output). I don't think it has been mentioned in this thread yet: https://patchwork.kernel.org/patch/9532535/ You are welcome to invite me to any issues which seem related to my patches :). --- > but it should not be doing that Attempting to create `/proc/self/fd/1` implies that it did not already exist. This suggests you found some way to run `fixfiles` without a file descriptor for standard output... Please remember to outline the specific circumstances you observed your issues under. When developers can reproduce issues and test fixes for themselves, it's the simplest way :). (My first reaction to "could it be my fault" is always "yes". This makes it hard to provide a useful response without getting very specific). The thing is that most *nix software makes sure to keep fds 0-2 open (hence /dev/null). Its not clear that this is a defect in fixfiles. I'm not even aware of a nice shellscript idiom, that fixfiles could use to "defend" against being run without standard output. (How do I test whether standard output has been closed?). What we would really want to fix is whatever software managed to close the standard output. The SELinux policy that causes those denials also sounds very suspicious to me, though I'm not sure what the best way to report that is. --- Running `sudo fixfiles check` on my Fedora 25 machine didn't produce any AVC denials... I think this patch is not in the Fedora 25 branch, but it is in master. Please always remember to cite your versions, to avoid wasting time, they are critical to understanding issues :). (Like the template you see when filing a new issue). I can't reproduce the denials even with 0. staying on Fedora 25 1. using fixfiles from upstream (9cba8f6), which includes both changes mentioned, and 2. running `sudo fixfiles check >&-`, i.e. with stdout closed. though, this shouldn't surprise me, as my `/usr/sbin/fixfiles` is not labelled to transition into something like `seutils.setfiles.subj`. (It's labelled `bin_t`, which doesn't transition. Running it from sudo will leave it unconfined). actually I've never seen contexts that look like `sys.id:sys.role:seutils.setfiles.subj:s0` or `sys.id:sys.role:fs.proc.fs:s0` You seem to be running a stricter SELinux policy, which I don't have on my systems. You should describe your system precisely enough that someone can understand where this is coming from. Most specifically, on my system, `/proc/*/fd/*` does not appear to ever be labelled with a blanket `fs.proc.fs`. Instead it appears to share the same label as the relevant process. This would avoid these denials. These denials look like a bug that seriously needs fixing.
alan> My first reaction to "could it be my fault" is always "yes" ...while I haven't noticed anything in `fixfiles` that would close stdout, I did realize my patch here which uses `/proc/self/fd` is bad. Just as wrong and in need of fixing as the previous approaches. So I should also be thanking you, for giving me a reason to look at it again :).
(In reply to Alan Jenkins from comment #15) > Please open a new issue to avoid cluttering this one. > > Assuming your issue was introduced by a recent update, the specific change > is probably an independent one (not required to fix the garbled output). I > don't think it has been mentioned in this thread yet: > > https://patchwork.kernel.org/patch/9532535/ > > You are welcome to invite me to any issues which seem related to my patches > :). > > --- > > > but it should not be doing that > > Attempting to create `/proc/self/fd/1` implies that it did not already > exist. This suggests you found some way to run `fixfiles` without a file > descriptor for standard output... Please remember to outline the specific > circumstances you observed your issues under. When developers can reproduce > issues and test fixes for themselves, it's the simplest way :). > > (My first reaction to "could it be my fault" is always "yes". This makes it > hard to provide a useful response without getting very specific). > > The thing is that most *nix software makes sure to keep fds 0-2 open (hence > /dev/null). Its not clear that this is a defect in fixfiles. I'm not even > aware of a nice shellscript idiom, that fixfiles could use to "defend" > against being run without standard output. (How do I test whether standard > output has been closed?). > > What we would really want to fix is whatever software managed to close the > standard output. > > The SELinux policy that causes those denials also sounds very suspicious to > me, though I'm not sure what the best way to report that is. > > --- > > Running `sudo fixfiles check` on my Fedora 25 machine didn't produce any AVC > denials... I think this patch is not in the Fedora 25 branch, but it is in > master. Please always remember to cite your versions, to avoid wasting > time, they are critical to understanding issues :). (Like the template you > see when filing a new issue). > > I can't reproduce the denials even with > > 0. staying on Fedora 25 > 1. using fixfiles from upstream (9cba8f6), which includes both changes > mentioned, and > 2. running `sudo fixfiles check >&-`, i.e. with stdout closed. > The issue is encountered on fedora 26. I ran `fixfiles onboot && reboot` > though, this shouldn't surprise me, as my `/usr/sbin/fixfiles` is not > labelled to transition into something like `seutils.setfiles.subj`. (It's > labelled `bin_t`, which doesn't transition. Running it from sudo will leave > it unconfined). The policy is different but please do not let that distract you from the events that were encountered: fixfiles was trying to create a file "/proc/self/fd/1" and this should not be happening AFAIK. The /proc/self/fd/1 should be a symlink to some terminal. > > actually I've never seen contexts that look like > `sys.id:sys.role:seutils.setfiles.subj:s0` or `sys.id:sys.role:fs.proc.fs:s0` > > You seem to be running a stricter SELinux policy, which I don't have on my > systems. You should describe your system precisely enough that someone can > understand where this is coming from. > > Most specifically, on my system, `/proc/*/fd/*` does not appear to ever be > labelled with a blanket `fs.proc.fs`. Instead it appears to share the same > label as the relevant process. This would avoid these denials. These > denials look like a bug that seriously needs fixing. The "fs.proc.fs" event was with regard to the file with type "seutils.fixfiles.subj" trying to associate with the proc file system (fs.proc.fs is the type of procfs filesystem)
Yes my policy is (probably) more strict than the policy that Red Hat ships, but I would expect that even the Red Hat policy would not allow fixfiles (/usr/libexec/selinux/selinux-autorelabel calling fixfiles to be more precise) to create files on the procfs. So my suspicion is that you should be able to reproduce: 1. make sure that selinux-autorelabel runs contained and not unconfined. 2. fixfiles onboot && reboot 3. journalctl -b -1 | grep -i denied The above should probably show you the events of fixfiles trying to create a /proc/self/fd/1 file. (provided that SELinux is instructed to not allow this behavior)
I wouldnt be surprised if in Red Hat policy `selinux-autorelabel` runs unconfined. Verify whether /usr/libexec/selinux/selinux-autorelabel is not of type `bin_t` if /usr/libexec/selinux/selinux-autorelabel is of type `bin_t` then systemd will run it in the unconfined `unconfined_service_t` domain and then you might not see the event where fixfiles is trying to create a file on the procfs
> The policy is different but please do not let that distract you from the events that were encountered: > > fixfiles was trying to create a file "/proc/self/fd/1" and this should not be happening AFAIK. The /proc/self/fd/1 should be a symlink to some terminal. I can agree with this statement a second time if you like :). Thanks for specifying `fixfiles onboot`. I don't know how much work this would be for me to reproduce yet. Please, since you already have the details to reproduce it, open a new bug so everyone can keep track of this properly. It has no relation to the issue described here, or the patch which I wrote to fix the issue. On the one hand, I wouldn't expect it to happen in Fedora 25, because `selinux-autorelabel` is still running `/sbin/fixfiles $FORCE restore > /dev/null 2>&1`. On the other hand, once those redirections are removed[1] I wouldn't expect systemd to screw up and _close_ stdout. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1415674 > The "fs.proc.fs" event was with regard to the file with type "seutils.fixfiles.subj" trying to associate with the proc file system (fs.proc.fs is the type of procfs filesystem) Thanks for your clarifications and report. So I mis-stated about your selinux policy. There's a difference between the file, and the containing directory. I guess this is still a difference between your policy and the normal one, but it's not one that I'm worried about. # ls -Zd /proc/1/fd system_u:system_r:init_t:s0 /proc/1/fd # ps -AZ | head -n2 LABEL PID TTY TIME CMD system_u:system_r:init_t:s0 1 ? 00:00:03 systemd
Hmm, so the issue *might* be as simple as putting something in selinux-autorelabel.service unit telling systemd not to close the file descriptor? anyhow: https://bugzilla.redhat.com/show_bug.cgi?id=1446929