On 2014-04-16 00:11, Schaufler, Casey wrote: >> 2. Additional groups, based on privileges >> > The second idea is based on using DAC. For the camera example, the device >> > node would be accessible for selected group (i.e. "chgrp camera >> > /dev/video1; chmod 0660 /dev/video1"). During application launch, launcher >> > would check policy and add the application process to appropriate >> > additional >> > groups. > Set a POSIX ACL on /dev/camera. The installer can update the ACL if > necessary. > Groups also work, but you're cluttering up /etc/group.
Doing it with POSIX ACLs would still require cluttering /etc/group. It would have to be done on ACL group class, not user class.This is because the full triplet(user, app, permission) must be supported. Consider privacy setting application that can list and toggle application permissions for a user. If Smack grants access to /dev/camera for an app and ACL grants it for a user, the user will not be able to switch it in settings per application. Just like Smack doesn't know about users, user class ACLs won't know about apps. So the idea for solving the problem with DAC must rely on groupsand adding application process to appropriate groups by launcher. ACLs can help if we need to give access to camera for more than one group. For example, if there is an existing setup that already relies on groupDAC access, it would be possible to add one more group formanaging privileges and notbreak existing setup. But I don' know if it's the caseand ACLs add more complexity(and possibly overhead).
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
