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.
Moray. "To err is human. To purr, feline"
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?
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?
selinux@lists.fedoraproject.org