Bruno Haible wrote:
Paolo Bonzini wrote:
Compiling a package without SELinux support can be a security problem.
...
I'd like to include this check in sed 4.2.1 to warn packagers about the
additional dependency.
Can you explain why 'sed' is to be bothered about selinux at all? 'sed'
does not do anything security relevant (uids, gids, passwords). It does
access files. But isn't the necessary logic abstracted in the open()
system call?
"sed -i" bothers. Since it needs to access the input file while it
creates the output file, it must recreate the file (*) and then copy it
to the old file name. In doing so it must copy the security context
just like it copies UIDs, GIDs, modes and ACLs.
(*) I had thought about mmaping the original file MAP_PRIVATE instead of
dealing with all these things. Unfortunately, asking for proper
copy-on-write semantics is a bit too much for sed, and it would have
hampered portability to mingw (mingw does have hard links, so the choice
to break them or keep them must be done uniformly on all platforms).
Besides, perl -i is also breaking hard links so sed doing the same is
not a bad idea.
Paolo
