linux-kernel - Re: sysfs permissions on dynamic attributes (led delay_on and delay

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120721160855.GB7565@khazad-dum.debian.net>
Date:	Sat, 21 Jul 2012 13:08:55 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Colin Cross <ccross@...roid.com>
Cc:	Richard Purdie <richard.purdie@...uxfoundation.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Bryan Wu <bryan.wu@...onical.com>
Subject: Re: sysfs permissions on dynamic attributes (led delay_on and
 delay_off)

On Sat, 21 Jul 2012, Colin Cross wrote:
> The delay_on and delay_off files could easily override the values from
> the trigger.
> 
> Sending a KOBJ_CHANGE uevent is not a great solution, it's still
> horribly racy in userspace.  This script would never work reliably:
> echo timer > trigger
> echo 1000 > delay_on
> echo 1000 > delay_off
> echo 255 > brightness

Yes, and the proper fix is to instead use a fully async userspace based on
uevent callbacks.  Nasty as all hell.  Or the quick fix, which is to wait
for the system to settle after every sysfs operation that could create new
sysfs nodes.

You could make sure that (1) no sysfs operation will return control to
userspace until it is complete, so you'd have all new sysfs nodes available
at the time the first echo returns [I believe it already works like that],
and (2) either enhance sysfs to create nodes with the desired ownership and
permissions -- which requires feeding policy rules to it beforehand at the
very least; or do it as whichever priviledged user/group has default write
access to sysfs nodes.

This is a general problem.  I have no idea whether Richard will allow the
triggers hack to work around it or not, and I really don't care.  But the
bad sideffects of the hack that he pointed out are all very true, and far
reaching in time.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/