Darren J Moffat wrote: > Jan Setje-Eilers wrote: >> Darren J Moffat wrote: >>> Enrico Perla wrote: >>>> >>>> Darren J Moffat wrote: >>>>> What is the method credential section of the SMF manifest used to >>>>> start the vbios service ? ie what user/group id does it run as and >>>>> what privileges(5) does it require. >>>> It runs as root and needs to open /dev/xsvc to map the BIOS image. >>>> After >>>> that, it needs to be able to do in/out assembly instruction (so, >>>> basically, it needs to be able to set its IOPL to 3). >>>> I haven't set so far any specific privilege on the daemon since either >>>> /dev/xsvc or in/out look to me as a pretty good way to take over the >>>> system, if vbiosd proves to be vulnerable. >>>> >>>> Actually, though, we are a bit re-designing vbiosd (there was another >>>> service that was only responsible of checking if gdm started and >>>> receiving SIGTHAW to catch resumes that we are merging into vbiosd in >>>> order to have a single service). Since that will likely lead to two >>>> different threads, maybe we want to separate the privileges there? What >>>> would be your suggestion? >>> >>> I'd say in that case you aren't ready for ARC review if you don't >>> know what vbiosd does. >> >> We do know what it does. Re-design is perhaps a stronger term than >> was appropriate here. Enrico was collapsing what were originally two >> daemons into one yesterday. He was primarily offering that he'd be >> happy to make additional changes if you had some smart ideas about how >> to deal with xsvc without running as root. > > So doesn't changing two daemons into one change the architecture of this > case ? Or is what is in the case the two daemons in one ? >
The case reflects the single daemon. In fact combining them was driven by the inevitable reaction that multiple daemons would provoke. -jan
