[Dev] Input device files group

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Tue Oct 28 17:07:20 GMT 2014

On 28/10/2014 17:23, Lukasz Pawelczyk wrote:
> On wto, 2014-10-28 at 14:51 +0100, Stéphane Desneux wrote:
>> Also, I'm not sure that the rules for defining the permissions on such
>> devices should be global. 

By 'global' I only meant 'enforced for any tizen profile'.

> Because:
> 1. The security policy is global and it's not to applications to define
> that. You have 2 packages that write potentially conflicting entries to
> the same file now (udev input rules). You might as well introduce a
> third that does something completely different.

The security policy is certainly not defined by apps, but a hardware
vendor must be able to tweak the security on his platform according to
its specificness. Making some restrictions for Tizen:IVI platforms is
not the same as restrictions for Tizen:Mobile. Some will be common to
both, some will be specific.

> Not to mention that this is so wrong on the RPM/filesystem consistency
> level. The files should be provided by RPM and installed together with
> the package, not created by post scripts. That's why there are config.d
> directories in the first place. Now you can't even see who added this
> entry and why. Every script can do as he wishes. A malicious app could
> add another entry to the file and rpm --verify wouldn't catch that.

I agree that the rules must be installed properly from a clean and
identified RPM (no post scripts). BUT for Tizen 3, I think that webapps
or native apps won't be available as RPMs: you'll only have choice on
wgt, tpk or xpk.

RPM is reserved for platform development. So, no worries on this point.

> 2. Because you might have packages on much lower level then X/wayland. I
> already gave examples. And those could be used on headless installations
> and want to rely on such permissions (which wouldn't exist without
> X/wayland installed).
> Security containers is a live example.

If we have some use cases that show that a device is shared across
multiple software components, it makes sense to define the rule only in
one location.

But take the list of udev rules in /lib/udev/rules.d: you'll see some
rules coming from systemd and others coming from the main package that
will use a given device: for example, alsa-utils or bluez.

So, there's no absolute scheme. We must adjust depending on the devices
and use cases.

>> And currently, you'll notice that every
>> profile is free to define the permissions as needed (because
>> weston-common or x11-common are packages specific to Tizen:Common, not
>> supposed to be inherited directly in a Tizen profile.
>> Why not specifying the input rules where the 'input' group is defined ?
> It only means that the input group is defined in the wrong place.

What's your suggestion for a better place ?

Best regards,

More information about the Dev mailing list