> > But this is not a bad reason. Allowing people to avoid running suid
> > programs is a *good* reason.
> Usually yes. But for a code that simply parses /dev/kmem content without
> taking args...
> Just took a quick look at dmidecode.c and auditing this code doesn't
> seem out of reach.
Exactly. And 90% of it can be ditched.
> What's the difference security-wise between running this code in kernel
> space and in a suid prog? Avoiding loading libraries?
> Frankly I don't see the point.
*shrug* about the same point as having a /proc/acpi/dsdt I'd guess.
(Which worked fine as a run-as-root program called acpidmp, but
for some reason someone thought it'd be good to dump in /proc)
-- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/