[prev in list] [next in list] [prev in thread] [next in thread] 

List:       systemd-devel
Subject:    [systemd-devel] [PATCH 2/3] udev: check return value of uname.
From:       zbyszek () in ! waw ! pl (Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?=)
Date:       2013-03-29 15:33:13
Message-ID: 20130329153313.GD3394 () in ! waw ! pl
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]