Some further comments from the 2009/202 case: - Darren Moffat said:
Artem Kachitchkine wrote: > Darren J Moffat wrote: >> Why can't this case and the braseo one use the services provided >> by svc:/network/rpc/smserver ? See rpc.smserverd(1M). > > Please don't use smserver/libsmedia to gain USCSI privileges. > > (Longer answer: > http://www.mail-archive.com/opensolaris-discuss at opensolaris.org/msg06641.html) > > > sys_devices is needed to issue raw SCSI ioctls. I'm not sure about > Linux, perhaps DAC permissions are sufficient there. Giving out sys_devices isn't IMO the correct answer either - particularly given that sys_devices is such a big powerful privilege. Instead I'd rather see a privilege specifically for these USCSI ioctls. However that still leaves the issue of why aren't the DAC permissions enough ? Why do we need more protection than that here ? Maybe the new uscsi privilege should be in the basic set ? - Nicholas Williams responds to Darrent's comments above with: Isn't this a logindevperm sort of issue?? - Artem Kachitchkine responds: > Giving out sys_devices isn't IMO the correct answer either - > particularly given that sys_devices is such a big powerful > privilege. > > Instead I'd rather see a privilege specifically for these USCSI > ioctls. However that still leaves the issue of why aren't the DAC > permissions > enough ? Why do we need more protection than that here ? Maybe > the new uscsi privilege should be in the basic set ? Quoting Tamarack (2005/399) inception materials: > We propose: > > - eliminate smserverd, make libsmedia open device directly; > - create two new privileges: > - uscsi_full for full uscsi access; > - uscsi_user for limited uscsi access (no resets or aborts); > - add uscsi_user to the "Basic User Profile"; However, we ended up removing this part of the proposal - I can't recall why exactly. Perhaps we moved it outside of the project scope while trying to finish the project before mgmt reprioritized again :) One thing to keep in mind is that uscsi can be used to do some nasty stuff. Like make a device behave in unpredictable ways, triggering dormant driver bugs; or reprogram its firmware to become a completely different class (make a USB disk behave like a USB microphone); or, on parallel SCSI, create bus conditions that would affect devices you may not have DAC permissions for; etc. -Artem
