cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults
rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3
src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5
src/share/man/man9 Makefile sensor_attach.9 src/sys/conf files ...
netchild at FreeBSD.org
Tue Oct 16 09:42:00 PDT 2007
Quoting John-Mark Gurney <gurney_j at resnet.uoregon.edu> (from Mon, 15
Oct 2007 13:21:15 -0700):
> Alexander Leidinger wrote this message on Mon, Oct 15, 2007 at 21:09 +0200:
>> > >I already told you last time
>> > >that the current way (access to the i2c or smbus) needs more access
>> > >rights than using the userland parts of the sensors framework.
>> > More rights than what exactly ?
>> One popular userland temperature/voltage reading tool (as it supports a
>> lot of popular devices) is mbmon. It is currently a SUID root
>> application. It is like this as it accesses the smbus and/or ISA I/O
>> ports directly. If we forget the ISA I/O ports part, we could maybe
>> switch to a mbmon-user, but I don't really want to have such an user be
>> able to query every device on the smbus.
>> systat and sysctl are not SUID/SGID and don't require some special
>> rights in /dev. I would say this is a big difference in favour of the
>> sensors framework.
> Did you completely ignore the discussion back in July? I didn't bring
> it up, because someone else did, but the simple solution is a socket
Have you a pointer to it? I would like to analyze why I don't remember
to have seen this.
> like /var/run/log or /var/run/devd.pipe, that a userland daemon running
> as root that has access to ISA I/O and related resources... It's
> that simple...
And the code doesn't exists. And when it is written, when will it be
bugfree enough? The sysctl way of exporting integer data already has a
good track record, and porting the existing lm sensor (from a project
which is known to take much care about security) was easier to get
right. The project also was not about the lm sensor (I don't go and
count the size for the small lm sensor now). The lm sensor was one
example of using it. I don't think objection to the lm sensor driver
should lead to removal of the framework itself. One possible reaction
could be to say that the lm sensor should move to ports.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
You can be replaced by this computer.
More information about the cvs-src