In case lstat(3) fails the memory is not free'd at the end of the for
loop, due to the control flow change by continue.
Found by scan-build.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
On Ubuntu 20.04, when building with clang -Werror -Wextra-semi-stmt
(which is not the default build configuration), the compiler reports:
secon.c:686:3: error: empty expression statement has no effect;
remove unnecessary ';' to silence this warning
[-Werror,-Wextra-semi-stmt]
};
^
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
I can't think of a good reason why they should be excluded. On the
contrary, excluding them can cause trouble very easily if some labeling
rules for these directories change. For example, we changed the label
for /dev/nvme* from nvme_device_t to fixed_disk_device_t in Fedora
(updating the allow rules accordingly) and after policy update they
ended up with an invalid context, causing denials.
Thus, remove /dev and /run from the excludes. While there, also add
/root to the basic excludes to match the regex that excludes fc rules
(that should be effectively no functional change).
I did a sanity check on my system by running `restorecon -nv /dev /run`
and it didn't report any label differences.
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Acked-by: Petr Lautrbach <plautrba@redhat.com>
Seems to have been there to allow for some sed substitution over the
text. Now that this is gone, the redundant intermediate file can be
removed, too.
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
It is quite useful even to non-privileged users and doesn't require any
privileges to work, except for maybe -v.
Some tools hard code the old path, so a compatibility symlink is also
created.
Signed-off-by: Jonathan Hettwer <j2468h@gmail.com>
Acked-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Resolve pathname before selinux_restorecon_xattr() to prevent problems
with 'No Match' when relative path is used.
Fixes:
# restorecon_xattr -v tmp
...
tmp Digest: f9cd2da7141068bd2c08bc02fa471db63ac7d44c No Match
# restorecon_xattr -v `pwd`/tmp
...
/root/tmp Digest: f9cd2da7141068bd2c08bc02fa471db63ac7d44c Match
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Mention the supported file systems ext4, gfs2 and btrfs.
The options check and verify are interchangeable, merge their
description.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Acked-by: Petr Lautrbach <plautrba@redhat.com>
Suggested-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Acked-by: Nicolas Iooss <nicolas.iooss@m4x.org>
`setfiles -d` doesn't have any impact on number of errors before it
aborts. It always aborts on first invalid context in spec file.
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Commit 602347c742 ("policycoreutils: setfiles - Modify to use
selinux_restorecon") changed behavior of setfiles. Original
implementation skipped files which it couldn't set context to while the
new implementation aborts on them. setfiles should abort only if it
can't validate a context from spec_file.
Reproducer:
# mkdir -p r/1 r/2 r/3
# touch r/1/1 r/2/1
# chattr +i r/2/1
# touch r/3/1
# setfiles -r r -v /etc/selinux/targeted/contexts/files/file_contexts r
Relabeled r from unconfined_u:object_r:mnt_t:s0 to unconfined_u:object_r:root_t:s0
Relabeled r/2 from unconfined_u:object_r:mnt_t:s0 to unconfined_u:object_r:default_t:s0
setfiles: Could not set context for r/2/1: Operation not permitted
r/3 and r/1 are not relabeled.
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Compilation of newrole with PAM and audit support currently requires that you have the respective headers installed on the host. Instead make the header location customizable to accomodate cross-compilation.
Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
By bind mounting every filesystem we want to relabel we can access all
files without anything hidden due to active mounts.
This comes at the cost of user experience, because setfiles only
displays the percentage if no path is given or the path is /
Signed-off-by: Jonathan Hettwer <j2468h@gmail.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
The -c option allows to check the validity of contexts against a
specified binary policy. Its use is restricted: no pathname can be used
when a binary policy is given to setfiles. It's not clear if this is
intentional as the built-in help and the man page are not stating the
same thing about this (the man page document -c as a normal option,
while the built-in help shows it is restricted).
When generating full system images later used with SELinux in enforcing
mode, the extended attributed of files have to be set by the build
machine. The issue is setfiles always checks the contexts against a
policy (ctx_validate = 1) and using an external binary policy is not
currently possible when using a pathname. This ends up in setfiles
failing early as the contexts of the target image are not always
compatible with the ones of the build machine.
This patch reworks a check on optind only made when -c is used, that
enforced the use of a single argument to allow 1+ arguments, allowing to
use setfiles with an external binary policy and pathnames. The following
command is then allowed, as already documented in the man page:
$ setfiles -m -r target/ -c policy.32 file_contexts target/
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
One thing that confused me when investigating
https://github.com/SELinuxProject/selinux/issues/248 (i.e.
https://github.com/coreos/fedora-coreos-tracker/issues/512) was that the
manual page for `setfiles` seemed to imply that paths were fully
resolved. This was consistent with the issues above where `setfiles` was
failing because the target of the symbolic link didn't exist.
But in fact, the wording around symbolic links in
`setfiles`/`restorecon` refers actually to whether the parent
directories are canonicalized via `realpath(3)` before labeling.
Clarify the man pages to explain this.
Signed-off-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
In case there are errors when committing changes to booleans, the
errors may not be reported to user except by nonzero exit status. With
"setsebool -V" it's possible to see errors from commit phase, but
otherwise the unfixed command is silent:
# setsebool -V -P secure_mode_insmod=off
libsemanage.semanage_install_final_tmp: Could not copy /var/lib/selinux/final/default/contexts/files/file_contexts to /etc/selinux/default/contexts/files/file_contexts. (Read-only file system).
libsemanage.semanage_install_final_tmp: Could not copy /var/lib/selinux/final/default/contexts/files/file_contexts to /etc/selinux/default/contexts/files/file_contexts. (Read-only file system).
Fixed version alerts the user about problems even without -V:
# setsebool -P secure_mode_insmod=off
Failed to commit changes to booleans: Read-only file system
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
Follow-up of: 9eb9c93275 ("Get rid of security_context_t and fix const declarations.")
Acked-by: William Roberts <william.c.roberts@intel.com>
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
hashtab_replace() and hashtab_map_remove_on_error() aren't used
anywhere, no need to keep them around...
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
When starting restorecond without any option the following redundant
console log is outputed:
/dev/log 100.0%
/var/volatile/run/syslogd.pid 100.0%
...
This is caused by two global variables of same name r_opts. When
executes r_opts = opts in restore_init(), it originally intends
to assign the address of struct r_opts in "restorecond.c" to the
pointer *r_opts in "restore.c".
However, the address is assigned to the struct r_opts and covers
the value of low eight bytes in it. That causes unexpected value
of member varibale 'nochange' and 'verbose' in struct r_opts, thus
affects value of 'restorecon_flags' and executes unexpected operations
when restorecon the files such as the redundant console log output or
file label nochange.
Cause restorecond/restore.c is copied from policycoreutils/setfiles,
which share the same pattern. It also has potential risk to generate
same problems, So fix it in case.
Signed-off-by: Baichuan Kong <kongbaichuan@huawei.com>
semodule -v will turn on semodule's own verbose logging but not logging
from CIL. This change makes the verbose flag also set cil's log level.
By default (ie no -v flag), this will enable CIL_ERR, and each -v will
increase the level from there.
Tested with a duplicated fcontext in the policy.
Before this change:
# semodule -v -B
Committing changes:
Problems processing filecon rules
Failed post db handling
semodule: Failed!
After this change:
# semodule -v -B
[ ... snip ... ]
Found conflicting filecon rules
at /var/lib/selinux/mcs/tmp/modules/400/mycustom/cil:159
at /var/lib/selinux/mcs/tmp/modules/400/mycustom/cil:158
Problems processing filecon rules
Failed post db handling
semodule: Failed!
Closes: https://github.com/SELinuxProject/selinux/issues/176
Signed-off-by: Jason Zaman <jason@perfinion.com>
The previous check used getfilecon to check whether / slash contains a label,
but getfilecon fails only when SELinux is disabled. Therefore it's better to
check this using selinuxenabled.
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Commit 6e289bb7bf ("policycoreutils: fixfiles: remove bad modes of "relabel"
command") added "$RESTORE_MODE" != DEFAULT test when onboot is used. It makes
`fixfiles -B onboot` to show usage instead of updating /.autorelabel
The code is restructured to handle -B for different modes correctly.
Fixes:
# fixfiles -B onboot
Usage: /usr/sbin/fixfiles [-v] [-F] [-f] relabel
...
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
"restorecon -n" (used in the "restore" function) has to be used with
"-v" to display the files whose labels would be changed.
Fixes:
Fixfiles verify does not report misslabelled files unless "-v" option is
used.
Signed-off-by: Vit Mojzis <vmojzis@redhat.com>
Use codespell (https://github.com/codespell-project/codespell) in order
to find many common misspellings that are present in English texts.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Remove legacy local boolean and user code, and to preserve API/ABI
compatibility the following functions int values should be set to '0'
as they are no longer used:
selinux_mkload_policy(int preservebools)
security_set_boolean_list(.... int permanent)
and the following are now no-op and return '-1':
security_load_booleans()
sepol_genusers()
sepol_set_delusers()
sepol_genbools()
sepol_genbools_array()
and these still return their paths for compatibility, however they are
marked as deprecated:
selinux_booleans_path()
selinux_users_path()
These have been removed as they are local functions only:
sepol_genusers_policydb()
sepol_genbools_policydb()
Also "SETLOCALDEFS" removed from SELinux config file and code.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
Update restorecon_xattr and man pages for new digest scheme
managed by selinux_restorecon(3).
Note that the Russian man pages require updating.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
According to [1], crypt() support in POSIX is optional, so include
also <crypt.h> when _XOPEN_CRYPT is not defined or is defined to -1.
Without this I can't build run_init from source out-of-the-box on
Fedora 29.
[1] http://man7.org/linux/man-pages/man3/crypt.3.html#NOTES
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
As reported in #123, setsebool immediately exits with an error if
SELinux is disabled, preventing its use for setting boolean persistent
values. In contrast, semanage boolean -m works on SELinux-disabled
hosts. Change setsebool so that it can be used with the -P option
(persistent changes) even if SELinux is disabled. In the SELinux-disabled
case, skip setting of active boolean values, but set the persistent value
in the policy store. Policy reload is automatically disabled by libsemanage
when SELinux is disabled, so we only need to call semanage_set_reload()
if -N was used.
Fixes: https://github.com/SELinuxProject/selinux/issues/123
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
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>
If the user has the $LINGUAS environment variable set, only translations
for those languages should be installed to the system.
The gettext manual [1] says:
"Internationalized packages have usually many ll.po files. Unless
translations are disabled, all those available are installed together
with the package. However, the environment variable LINGUAS may be set,
prior to configuration, to limit the installed set. LINGUAS should then
contain a space separated list of two-letter codes, stating which
languages are allowed."
[1]: https://www.gnu.org/software/gettext/manual/html_node/Installers.html#Installers
Signed-off-by: Jason Zaman <jason@perfinion.com>
In extract_pw_data(), if "getpwuid(uid)" fails, the function returns an
error value without initializing main's pw.pw_name. This leads main() to
call "free(pw.pw_name)" on an uninitialized value.
Use memset() to initialize structure pw in main().
This issue has been found using clang's static analyzer.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
