[Dev] Access control design for user applications

Rafał Krypa r.krypa at samsung.com
Wed Apr 16 10:21:54 GMT 2014

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140416/466dd092/attachment.html>

More information about the Dev mailing list