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 -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux