On Fri, 2010-01-29 at 10:29 -0500, Stephen Smalley wrote:
On Fri, 2010-01-29 at 12:38 +0000, Moray Henderson wrote:
> Fixfiles in selinux-policy-targeted-2.4.6-255.el5_4.3.noarch cannot cope
> with a cr/lf sequence occurring in a file name. I'm not sure I can
> either, come to that, but one of my users somehow managed to create
> himself a file with the MS-DOS line termination sequence embedded in its
> name. The directory tree needed a relabel, and fixfiles threw lstat
> errors when it hit that file.
>
> The file was called
> __history/Ict.Petra.Client.MCommon??.UC_PartnerAddresses.Logic.pas.~1~
> (with the double-question mark being the offending characters) and
> fixfiles complained
>
> lstat(__history/Ict.Petra.Client.MCommon^M) failed: No such file or
> directory
> lstat(.UC_PartnerAddresses.Logic.pas.~1~) failed: No such file or
> directory
> lstat(__history/Ict.Petra.Client.MCommon^M) failed: No such file or
> directory
> lstat(.UC_PartnerAddresses.Logic.pas.~1~) failed: No such file or
> directory
>
> It's probably a bug, but whether it's in fixfiles or in my user is
> harder to determine.
Bug in the fixfiles script; it runs find with a set of expressions and
feeds the output to restorecon. Dan, can we just directly invoke
restorecon these days since it internally detects mounts that do not
support seclabel and skips them?
Oh, wait - I missed the fact that this was on RHEL5.
Looking more closely I see that modern /sbin/fixfiles passes -print0 to
find and -0 to restorecon to avoid problems with whitespace in the
filenames. Maybe RHEL5 doesn't have that change?
--
Stephen Smalley
National Security Agency