On Fri, Mar 29, 2013 at 04:20:29PM +0100, Lennart Poettering wrote: > Not really. SELinux checks labels of objects against labels of processes > really. uname(), gettimeofday(), getpid() and things like that aren't > really affected, since they don't really do anything on any objects. > > I mean, doing assert_se() around them is already more than these > syscalls deserve I guess, since realistically they cannot fail. And if > they do fail, then there's something really really wrong with the > security policy. Much much wronger than just a mislabelled file > somewhere... In such a corner case I think it is fine to asserts. > > To me this is like checking for IO errors on stderr after logging > something, or if we'd verify each time when we invoke snprintf() that > the resuling string parses back to the same number with strtoull. > > But anyway, it's a bit of a bikeshedding thing about where you draw the > line between "this is clearly a programming error condition" and "this > is clearly a runtime error condition"... All true. But asserts confuse people: look how some failing conditions in tests make people immediately think that something segfaulted. And in this case dumping core is completely useless, and a log error line tells just as much and is nicer to the user.
Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
