musl doesn't implement GLOB_BRACE and GLOB_TILDE, so simply don't use
them there. This only affects "setfiles -f", which I don't expect many
people use, and it's undocumented anyway that it expands globs.
Signed-off-by: Luis Ressel <aranea@aixah.de>
Signed-off-by: Jason Zaman <jason@perfinion.com>
Fix the following ambiguous output (from booting with init=/bin/sh):
# /usr/sbin/fixfiles onboot
/usr/sbin/fixfiles: line 313: /.autorelabel: Read-only file system
/usr/sbin/fixfiles: line 317: /.autorelabel: Read-only file system
System will relabel on next boot
System will not relabel on next boot if we couldn't create ./autorelabel
(In case anyone reading this description is still confused: To run
`fixfiles onboot` after booting with init=/bin/sh, you must first run
`mount / -oremount,rw`).
clang's static analyzer reports a potential memory leak because the
buffers allocated in pc and fc are not freed in main(), in sestatus.c.
Free these buffers properly.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
"sestatus -v" uses /proc/$PID/exe symbolic link in order to find the
context of processes present in /etc/sestatus.conf. For example, this
file includes "/usr/sbin/sshd".
On Arch Linux, /bin, /sbin and /usr/sbin are symbolic links to /usr/bin,
so sshd process is seen as "/usr/bin/sshd" instead of "/usr/sbin/sshd".
This causes "sestatus -v" to show nothing in "Process contexts:" for
sshd, agetty, etc.
Use realpath() to resolve any symlink components in program paths
defined in /etc/sestatus.conf. This makes "sestatus -v" show the
expected result:
Process contexts:
Current context: sysadm_u:sysadm_r:sysadm_t
Init context: system_u:system_r:init_t
/sbin/agetty system_u:system_r:getty_t
/usr/sbin/sshd system_u:system_r:sshd_t
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Unify behaviour for all module actions.
The same behaviour is already present for -i/-u/-r/-e switches.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1545218
Signed-off-by: Vit Mojzis <vmojzis@redhat.com>
Unify the way parameters are described in man pages and --help message.
Explain special syntax allowing the user to specify multiple modules when using
-i/u/r/E mods.
Point out that priority has to be specified in order to remove module at
different priority than 400 and that "-d" disables all instances of
given module across priorities.
Resolves: rhbz#1320565, rhbz#1337192
Signed-off-by: Vit Mojzis <vmojzis@redhat.com>
Making stdin/stdout non-blocking causes open_init_pty to hang if
they are closed, ala
./open_init_pty bash -c 'echo hello; exec >&- 2>&- <&-; sleep 1; '
and per
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474956#10
This reverts commit fb081eb64b.
Reported-by: Laurent Bigonville <bigon@debian.org>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
As reported by Nicolas Iooss, there are still some inconsistencies
in the definitions and usage of Makefile variables related to bin
and sbin directories. Since we need to still support non-usrmerge
systems, we cannot completely synchronize them, but we can eliminate
unnecessary differences, remove unused variables, and drop the
USRSBINDIR variables.
Before:
$ find . -name Makefile -exec cat {} + |grep '^[A-Z_]*BINDIR' |sort -u
BINDIR=$(PREFIX)/bin
BINDIR ?= $(PREFIX)/bin
BINDIR ?= $(PREFIX)/sbin
SBINDIR ?= $(DESTDIR)/sbin
SBINDIR ?= $(PREFIX)/sbin
USRSBINDIR ?= $(PREFIX)/sbin
After:
$ find . -name Makefile -exec cat {} + | grep '^[A-Z_]*BINDIR' | sort -u
BINDIR ?= $(PREFIX)/bin
SBINDIR ?= $(DESTDIR)/sbin
SBINDIR ?= $(PREFIX)/sbin
This does not change the actual install location of any file.
It does drop the legacy symlink from /usr/sbin/load_policy to
/sbin/load_policy; packagers can create that separately if
desired.
Reported-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
There were several places in the makefiles where LDLIBS or CFLAGS were
supposed to include options to build. They were missing the override
keyword so would be skipped if these vars were set on the make cmdline.
Add the override directive to fix this.
Signed-off-by: Jason Zaman <jason@perfinion.com>
Files in /tmp, /var/tmp, /var/run and /var/lib/debug labeled as
unlabeled_t or undefined_t are relabeled to match corresponding
directory label. Stop dereferencing link files in these folders
in order not to accidentally change label of other files in the
system.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1458831
Signed-off-by: Vit Mojzis <vmojzis@redhat.com>
when building packages (e.g. for openSUSE Linux)
(random) filesystem order of input files
influences ordering of functions in the output,
thus without the patch, builds (in disposable VMs) would usually differ.
See https://reproducible-builds.org/ for why this matters.
* `fixfiles -B relabel` or `fixfiles -C previouscontext relabel` would
skip the code that handles e.g. `/var/tmp`, which would be run by
`fixfiles relabel`. It would still remove all files in /tmp (subject to
user confirmation). This is confusing, undocumented, and unlikely to
be intentional.
* `fixfiles relabel path1 path2` is the same, except it would only relabel
the first path.
* `fixfiles -R ... relabel` was equivalent to `fixfiles -R ... restore`,
again contradicting the man page.
Also `fixfiles onboot` would ignore paths, -C, or -R.
fixfiles is mostly for users, where it should be acceptable to remove these
non-sensical combinations.
`fixfiles -C` is used in selinux-policy rpm install scripts. However I
believe the rpms used `fixfiles -C previouscontext restore`, and did not
either require user interaction or blow away /tmp without prompting. So
they should still work fine.
With these combinations removed, we can remove the `exit` calls which were
seen in some of the (non-error) code paths in `restore()`.
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
`fixfiles -R -a` is much less useful than it was made to sound, because -R
now works recursively. Therefore `fixfiles -R -a` relabels every file on
the system, multiple times. On my system it took over 5 times as long as
plain `fixfiles` (which takes about a minute).
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
This commit allows the use of `set -u` to detect reads of unset variables.
But what I really liked was making the code more explicit about these
modes. I hope that this is easier for a new reader to reason about.
`fixfiles restore` has accumulated five different modes it can run in.
Now use a single variable to indicate the mode, out-of-band of the
variables used for the individual modes.
Apparently `set -u` / `set -o nounset` doesn't work correctly with arrays.
If we ever need bash arrays, we can simply remove `set -u`. The `set -u`
dialect is a strict subset. See http://mywiki.wooledge.org/BashFAQ/112
Extra notes:
RESTORE_MODE was created because I couldn't bring myself to use an empty
FILEPATH, as a special case to indicate the default mode. Arguments
to the script (paths) could be empty already, so it would mean I had to
work out how we behaved in that case and decide whether it was reasonable.
It turns out the `-B | -N time` mode is distinct and does not respect
paths. So we can tell the user we're not going to do anything with the
paths they passed. Make sure this distinction is shown in the usage error
message.
We already rejected the combination of `-R rpmpackage,... dir/file...`.
Being aware of the different modes just causes more bogus combinations
to be rejected.
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
New users may try something like `fixfiles restore -v /dir/file` -
not realizing they are required to use `fixfiles -v restore /dir/file`.
Detect that `restorecon` aborts due to being run on the non-existent file
`-v`, and stop immediately. This will show the error much more clearly,
instead of continuing to restore `/dir/file` *without* verbose messages.
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
The idea is to print a usage error, then terminate with EXIT_FAILURE.
Don't print the usage error twice when run with no command.
Don't try to check for bogus extra arguments _after_
performing a long-running operation... particularly
if that operation terminates the script with EXIT_SUCCESS first.
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
$ shellcheck fixfiles
...
In fixfiles line 94:
[[ "${i}" =~ "^[[:blank:]]*#" ]] && continue
^-- SC2076: Don't quote rhs of =~, it'll match
literally rather than as a regex.
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
DIRS was suspicious because you can't store file names in a normal variable,
and it's not that common to use arrays in bash. It's not actually used.
While we're here, there's another variable which is never used
and should just be removed. (Pointed out by `shellcheck`.
It makes a couple of other points too, but I have more specific
patches I want to put those in).
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
Make sure usage() in fixfiles shows all the current options.
It's printed when there's a user error, so it needs to be
helpful! (Excluding the deprecated option - see below).
manpage:
Remove the deprecated option `-l logfile`.
Add missing space in `restore|[-f] relabel`.
It's not clear why `-R rpmpackagename` was considered optional in the
second invocation. (If the user omits it, they are just performing the
first invocation). It desn't match usage() in fixfiles either.
Clean up bolding for `fixfiles onboot`.
Disable justification (troff "adjustment") in the synopsis. We want the
common options in the different invocations to line up consistently.
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
...and write log messages to standard output.
Some versions of fixfiles in 2004 created a logfile by default.
Apparently they also used `tee` to log to standard output at the same time.
We're also told that the logfile was implemented because there was too
much output generated for use on a tty, and it scrolled out of reach.
https://bugzilla.redhat.com/show_bug.cgi?id=131707
In the current version, none of these original reasons for `-l` remain.
The logfile is not created by default. If no log file is specified,
messages are written to stdin [sic]... if and only stdin is a tty. If
stdin is not a tty, the log defaults to /dev/null.
When a user runs fixfiles on a tty and finds there is too much output, she
is likely to try redirecting standard output and/or standard error using
the shell. She will find this doesn't help, because fixfiles is writing
the verbose log messages to standard input.
I tried to fix the problem non-intrusively, by changing the default log
file to `/dev/stdout`. Sadly, this breaks down where you have
`echo >>$LOGFILE "Log message"` inside a specific function, which is run
with output redirected in order to "return" a string value (captured
into a variable). exclude_dirs_from_relabelling() was such a function.
I was trying to abstract over writing to both normal files and stdout, but
my abstraction "leaks" in a non-obvious way.
There is a simple solution. We can write the log messages to standard
output. When we are passed `-l` by a legacy script, we can redirect
standard output to the logfile.
This removes any distinctions between the logfile and "non-log" messages.
Some calls to restorecon were missing redirections to the log file.
"Cleaning out /tmp" was written to the log file, but "Cleaning out labels
on /tmp" was not. There were no comments to explain these distinctions.
Move call to logit() outside a function which has its output redirected.
See next commit for explanation.
The logit calls are moved into a new function LogExcluded(), similar to
LogReadOnly(). I don't see a pretty way to resolve this, so I just went
for the most explicit approach I could think of.
Behaviour change: diff_filecontext will now log *all* excluded paths.
I think that approach is an improvement, because e.g. the fact that `-C`
mode excludes `/home` was not previouslly documented anywhere.
The LogReadOnly() call which warns the user about R/O filesystems, applies
to the `-B` mode (newer() function), and the `fixfiles check` mode
(no paths).
Make sure to print it for these modes, and these modes only.
The usage of exclude_dirs() is non-obvious.
It turns out it is only used by the `-C` mode of fixfiles. The other four
modes use the narrower list generated by exclude_dirs_from_relabelling().
Let's make this distinction more obvious.
(The purpose of the extra exclusions is not clear. E.g. there's an
exclusion for /dev. Whereas the `fixfiles check` mode explicitly tells you
that it's going to relabel /dev, without causing any problem. Maybe that
part is out of date? But without some explanation of the list, I don't
want to change anything!)
setfiles is now run with $exclude_dirs.
We shouldn't need to patch the file contexts as well.
This is fortunate, since the file context patching code was broken
(by the same commit which introduced the redundancy). It takes the
list of directories to exclude from $tempdirs, but $tempdirs is
never set.
Also messages about skipping directories were printed twice. Firstly when
exclude_dirs is generated, and secondly in the file context patching code.
Also TEMPFCFILE was only removed in one path out of several.
This reverts commit ac7899fc3a,
which is not yet part of an officially tagged release
(or release candidate).
`LOGFILE=/proc/self/fd/1` was wrong.
`LOGFILE=$(tty)` was being relied on in one case (exclude_dirs),
to log messages from a function run specifically with stdout redirected
(captured into a variable).
Having `logit "message"` break inside redirected functions
is a nasty leaky abstraction.
This caused e.g. `fixfiles restore` to terminate early with the error
skipping: No such file or directory
if the user had configured any excluded paths in
/etc/selinux/fixfiles_exclude_dirs
The toolchain automatically handles them and they break cross compiling.
LDFLAGS should also come before object files, some flags (eg,
-Wl,as-needed) can break things if they are in the wrong place)
Gentoo-Bug: https://bugs.gentoo.org/500674
Signed-off-by: Jason Zaman <jason@perfinion.com>
