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 ...

[Alexander Leidinger]

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.

Bye,
Alexander.

-- 
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.