I suggested that if you run a command for its informational output (by
passing `-v`), you don't expect it to be prefixed with the program name.
Prefixing is used for error messages, so you can tell where your shell
script blew up :). If a script is running a command for its informational
output, it's usually the script's responsibility to make sure it's in
context, e.g. providing headers if there are multiple sections of output.
Removing the program name from setfiles/restorecon output is particularly
useful because it generates very long lines. But also, it actually helps
highlight where there are error messages - the prefix will make them
stand out visually.
Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
This fixes the following bug:
UX regression: setfiles progress indicator is now misleading and
confusing in fixfiles.
The outputting of * is replaced by the number of files in 1k increments
as the previous versions. If "/" is specified on the pathname, then this
will indicate a mass relabel, an example output will be:
restorecon -nRp /etc /tmp /boot /
/etc 100.0%
/tmp 100.0%
/boot 100.0%
3.2%
Also setfiles(8) and restorecon(8) versions that are implemented using
the selinux_restorecon(3) function do not support the [-o filename]
option as this was deprecated. This has now been made clear by displaying
a message to stderr.
The documentation has also been updated to reflect these changes.
Reported-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
Define a logging callback for libselinux so that any informational
or error messages generated by libselinux functions are properly
prefixed with the program name and routed to the proper output stream.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Reverse the sense of the -D option, from disabling setting/use of
security.restorecon_last to enabling it, making disabled the default state.
Rationale:
1) Users often use restorecon to fix labels on files whose labels are
wrong even through nothing has changed in file_contexts, e.g. after
copying/moving files to a different location. They won't expect
restorecon to suddenly stop relabeling by default because the hash of
file_contexts hasn't changed.
2) Only processes running with CAP_SYS_ADMIN can set
security.restorecon_last, so this will fail for non-root users anyway.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Add -D option to setfiles and restorecon - Do not set or update
directory SHA1 digests when relabeling files. This will allow
users the option of not using the "security.restorecon_last"
extended attribute feature.
Also review and update the man pages.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
Modify setfiles and restorecon to make use of the libselinux
selinux_restorecon* set of functions.
The output from these commands should be much the same as before
with some minor wording changes, the only exceptions being that for
setfiles(8) and restorecon(8) the following options have been added:
1) -I to ignore checking the directory digests.
2) -m to ignore reading /proc/mounts.
These additional options are described in the updated man pages.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
A spec file was incorrectly stored as rootpath when -r option was used
Fixes:
/sbin/setfiles: /tmp/install_root is not located in /etc/selinux/targeted/contexts/files/file_contexts
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
In C, defining a function with () means "any number of parameters", not
"no parameter". Use (void) instead where applicable and add unused
parameters when needed.
Acked-by: Steve Lawrence <slawrence@tresys.com>
This patch started with work from John Reiser patch to estimate the
percent progress for restorecon/setfiles.
It has a lot of changes since then, to make it only happen on full
relabel, overwrite itself, shows 10ths of %, and does a lot better and
more useful job of estimation. We get all of the inodes on all mounted
FS. Since the number of inodes is not fixed and only an estimate I added
5% to the inode number, and forced the number to never go over 100.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
process_one_realpath returns 1 if it changed the context of the file but
process_glob treats all non-zero values as errors. This results in
setfiles exiting with non-zero status even though it was successful.
Fix process_glob to only treat negative return values of
process_one_realpath as errors.
cf. http://bugs.debian.org/662990
Signed-off-by: Martin Orr <martin@martinorr.name>
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
- improves the manual page for both setfiles and restorecon (formatting
including alphabetical re-ordering of options, undocumented options,
references and a few cosmetic changes);
- de-hardcodes a couple of constants in the source files and makes a
dynamic use of them to create the manual pages after the compilation
and prior to the installation: more specifically the constants are the
number of errors for the setfiles' validation process abort condition
and the sensitivity of the progress meter for both programs (uses
external programs grep and awk);
- improves the usage message for both programs and introduces a -h
(aliased with currently existing -?) option where not already
available;
- print out the usage message for restorecon when it is called without
arguments;
- white-space/tab conversion to get proper indentation towards the end
of the main source file.
[eparis add .gitignore]
Signed-off-by: Guido Trentalancia <guido@trentalancia.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
We have some useless globals in setfiles that don't need to be. Stop
it.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
move exclude_non_seclabel_mounts from setfiles.c to restore.c so it can
be used by other functions later.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
Use the glob library to handle ~ and . in filenames passed from the
command line.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
The error usable displays r_opts.rootpath, but r_opts is supposed to be
an internal code thing, not something users care about. When printing
the error message just call it 'rootpath'
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
restorecon and fixfiles both have the -p option to display a * every
10000 files. Put it in the usage and man pages.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
We have dumb code in setfiles which will set a static variable called
ignore_enoent. Thing is, nothing uses it. So move the setting to where
it is useful and use it!
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
Email: tliu@redhat.com
Subject: policycoreutils: share setfiles restore function with restorecond
Date: Wed, 19 Aug 2009 15:51:44 -0400
This is the first of two patches.
This patch splits all of the restore functionality in setfiles
into another two files, restore.c and restore.h.
The reason for this is shown in the next patch, which patches
restorecond to share this code.
To use it, instantiate a restore_opts struct with the proper options
and then pass a pointer to it into restore_init, and call restore_destroy
later.
Signed-off-by: Thomas Liu <tliu@redhat.com>
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
I've rebased this so that it will apply to current trunk.
Signed-off-by: Chad Sellers <csellers@tresys.com>
Setfiles now checks the capabilities on the mounted file systems for
'seclabel' (see setfiles/setfiles.c:723:exclude_non_seclabel_mounts) on
newer kernels (>=2.6.30 see setfiles.c:734). However the 'seclabel'
feature is not available if selinux is not enabled. The result is that
setfiles silently fails to relabel any filesystems.
The patch below removes the check for seclabel if selinux is disabled.
As an alternative maybe seclabel should be available even if selinux is
disabled? It seems that whether a fs supports security labels is
independent of selinux being enabled.
Signed-off-by: Joshua Brindle <method@manicmethod.com>
Based on a patch by Martin Orr.
Restore the code to compute the realpath of all but the last component
of a symlink, and relabel both the symlink and (if it exists) the target
of the symlink when a symlink is specified to restorecon.
Thus, restorecon -R /etc/init.d will restore both the /etc/init.d symlink
context and the directory tree starting from /etc/rc.d/init.d.
This fixes the restorecon /dev/stdin performed by the Debian udev init
script that was broken by policycoreutils 2.0.70.
[sds: switched use of _realpath suffix for process_one, and dropped warning
on non-existent target]
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
On Tue, 2009-08-11 at 08:12 -0400, Daniel J Walsh wrote:
> On 08/10/2009 04:12 PM, Stephen Smalley wrote:
> > On Mon, 2009-08-10 at 16:03 -0400, Stephen Smalley wrote:
> >> On Mon, 2009-08-10 at 11:13 -0400, Daniel J Walsh wrote:
> >>> Currently in F12 if you have file systems that root can not read
> >>>
> >>> # restorecon -R -v /var/lib/libvirt/
> >>> Can't stat directory "/home/dwalsh/.gvfs", Permission denied.
> >>> Can't stat directory "/home/dwalsh/redhat", Permission denied.
> >>>
> >>> After patch
> >>>
> >>> # ./restorecon -R -v /var/lib/libvirt/
> >>
> >> But if you were to run
> >> ./restorecon -R /home/dwalsh
> >> that would try to descend into .gvfs and redhat, right?
> >>
> >> I think you want instead to ignore the lstat error if the error was
> >> permission denied and add the entry to the exclude list so that
> >> restorecon will not try to descend into it. It is ok to exclude a
> >> directory to which you lack permission. Try this:
> >
> > Also, why limit -e to only directories? Why not let the user exclude
> > individual files if they choose to do so? In which case we could drop
> > the mode test altogether, and possibly drop the lstat() call altogether?
> > Or if you truly want to warn the user about non-existent paths, then
> > take the lstat() and warning to the 'e' option processing in main()
> > instead of doing it inside of add_exclude().
> >
> I agree lets remove the directory check and warn on non existing files.
Does this handle it correctly for you?
Remove the directory check for the -e option and only apply the
existence test to user-specified entries. Also ignore permission denied
errors as it is ok to exclude a directory or file to which the caller
lacks permission.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Change setfiles/restorecon to only call realpath() on the user-supplied
pathnames prior to invoking fts_open(). This ensures that commands such
as restorecon -R /etc/init.d and (cd /etc && restorecon shadow gshadow)
will work as expected while avoiding the overhead of calling realpath()
on each file during a file tree walk.
Since we are now only acting on user-supplied pathnames, drop the
special case handling of symlinks (when a user invokes restorecon
-R /etc/init.d he truly wants it to descend /etc/rc.d/init.d). We can
also defer allocation of the pathname buffer to libc by passing NULL
(freeing on the out path) and we can drop the redundant exclude() check
as it will now get handled on the normal path.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
On Fri, 2009-07-24 at 16:12 -0400, Stephen Smalley wrote:
> On Fri, 2009-07-17 at 10:48 -0400, Thomas Liu wrote:
> > Get setfiles to check paths for seclabel and skip them
> > if it is not supported.
> >
> > Parse /proc/mounts and add paths that do not have seclabel
> > to the exclude list. If another path shows up that does
> > have seclabel, remove it from the exclude list, since setfiles
> > will try and when it fails it will skip it.
> >
> > Also made one of the error messages in add_exclude more
> > descriptive.
> >
> > Signed-off-by: Thomas Liu <tliu@redhat.com>
> > Signed-off-by: Dan Walsh <dwalsh@redhat.com>
> > ---
>
> Thanks, merged in policycoreutils 2.0.68.
Applied this patch on top to free the buffer allocated by getline() and
to free any removed entries from the excludeArray. valgrind
--leak-check=full then shows no leakage.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Get setfiles to check paths for seclabel and skip them
if it is not supported.
Parse /proc/mounts and add paths that do not have seclabel
to the exclude list. If another path shows up that does
have seclabel, remove it from the exclude list, since setfiles
will try and when it fails it will skip it.
Also made one of the error messages in add_exclude more
descriptive.
Signed-off-by: Thomas Liu <tliu@redhat.com>
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This is version 5 of the setfiles to fts patch.
The code has been cleaned up to adhere to the CodingStyle guidelines.
I have confirmed that the stat struct that fts returns for a symlink when using
the FTS_PHYSICAL flag is in fact the stat struct for the symlink, not the file
it points to (st_size is 8 bytes).
Instead of using fts_path for getfilecon/setfilecon it now uses fts_accpath,
which should be more efficient since fts walks the file hierarchy for us.
FreeBSD setfsmac uses fts in a similar way to how this patch does and one
thing that I took from it was to pass the FTSENT pointer around instead of
the names, because although fts_accpath is more efficient for get/setfilecon,
it is less helpful in verbose output (fts_path will give the entire path).
Here is the output from running restorecon on /
(nftw version)
restorecon -Rv / 2>/dev/null
restorecon reset /dev/pts/ptmx context system_u:object_r:devpts_t:s0->system_u:object_r:ptmx_t:s0
(new version)
./restorecon -Rv / 2>/dev/null
./restorecon reset /dev/pts/ptmx context system_u:object_r:devpts_t:s0->system_u:object_r:ptmx_t:s0
Here are some benchmarks each was run twice from a fresh
boot in single user mode (shown are the second runs).
(nftw version)
restorecon -Rv /usr
real 1m56.392s
user 1m49.559s
sys 0m6.012s
(new version)
./restorecon -Rv /usr
real 1m55.102s
user 1m50.427s
sys 0m4.656s
So not much of a change, though some work has been pushed from kernel space
to user space.
It turns out setting the FTS_XDEV flag tells fts not to descend into
directories with different device numbers, but fts will still give back the
actual directory. I think nftw would completely avoid the directories as well
as their contents.
This patch fixed this issue by saving the device number of the directory
that was passed to setfiles and then skipping all action on any directories
with a different device number when the FTS_XDEV flag is set.
Also removed some code that removed beginning and trailing slashes
from paths, since fts seems to handle it.
Signed-off-by: Thomas Liu <tliu@redhat.com>
[sds: Moved local variable declarations to beginning of process_one.]
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Email: dwalsh@redhat.com
Subject: setfiles will only put out a "*" if > 1000 files are fixed.
Date: Wed, 20 May 2009 13:08:14 -0400
setfiles was always putting out a \n, even when not many files were
being fixed. yum transactions were being desturbed by this.
Signed-off-by: Joshua Brindle <method@manicmethod.com>