[Dev] Input device files group

Stéphane Desneux stephane.desneux at open.eurogiciel.org
Wed Oct 29 17:10:33 GMT 2014


On 29/10/2014 11:14, Lukasz Pawelczyk wrote:
> On wto, 2014-10-28 at 18:07 +0100, Stéphane Desneux wrote:
>>> 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.
> 
> I didn't say apps, I said applications. Wayland, X.org, those are
> applications. In 99% they will be installed, but they are not mandatory
> for the platform.
> 
> You guys still bring up the argument of different profiles. The

Who ? And do you think that this argument doesn't make sense ?

> discussion is why the /dev permissions policy should not be in
> X.org/wayland. Profiles don't matter here. If the policy were in udev

As I already said, for input devices, as long as no other daemon uses
these devices, this is questionable. If you bring a new use case that
makes a device possibly shared amongst multiple daemons, things can be
reconsidered and of course, we can change the way of setting the
permissions.

I just say that it's one way to do things, and usually this is the
chosen way on many linux distros: take for example opensuse and sane
backends: you'll find a udev rule to set permissions on scanner devices
and the rule is distributed by sane-backends.rpm.

For Tizen, we can also chose another way. That's why we have this
discussion here.

> (or a related package) as I think it should you could still make it
> different per profile and let vendor modify it to his own wishes.

Modify = making branches on systemd ? Or simply create a specific git
tree profile/myprofile/udev-profile-policy.git where the vendor would
store its own rules ? I prefer the 2nd option.

> If you don't want it directly in udev rpm it could be udev-policy.rpm
> with different versions per profile. The are multiple solutions.

I think that defining all rules in a single place, be it in udev or
somewhere else is not very flexible if there's only one package,
inherited by all tizen profiles.

So why not introduce some freedom for profiles and/or vendors by having:
* a global package (say platform/core/security/udev-global-policy.git)
* a per-profile package (profile/${profile}/udev-profile-policy.git
(which shouldn't conflict with the global one)

?

And finally, let's find a if we should allow or forbid udev rules inside
other packages.

> 
>>> 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.
> 
> Of course it is. And I am talking about platform development. You seem
> to say that because apps don't touch RPM it justifies having
> inconsistent platform. Hmm.

That's what you interpreted, but that's not what I'm saying... And BTW,
why would I want to have an inconsistent platform ???

>>> 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.
> 
> IMO it always makes sense to have it in one place _if_ the policy
> concerns a global object. input devices are global. They exist
> regardless of anything else in userspace.
> 

Yes, I agree. But that doesn't implies that the policies should be
defined in a single place.

>> 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.
> 
> And IMO that is still incorrect.
> 
>> So, there's no absolute scheme. We must adjust depending on the devices
>> and use cases.
> 
> Devices are global. About use cases you have 2 cases:
> 1. there is one daemon/applications that is interested in the specific
> policy regarding a specific object.
> 2. there are 2 or more (like in wayland/x/security-containers).

Just to clarify on what's currently in Tizen:Common and what's not:
it's wayland OR X (not both in the same image) and security-containers
are not yet in Tizen:Common. So currently, we can think of input devices
as "reserved" devices to weston of xorg server.

> In the first case in theory it doesn't matter. But having this globally
> increases visibility and you never know when another interested party
> shows up.
> In the second case you even have to make it global, otherwise every RPM
> you install will add another policy that might be incompatible with the
> previous creating chaos.
> 

So, if we agree, the consequence would be that we should forbid the udev
rules in any package, except the two ones I suggested above (for a given
profile): udev-global-policy and udev-profile-policy, right ?

>>>> 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 ?
> 
> I already said, udev. Or some separate udev subpackage (udev-rules,
> udev-dev-policy). Or whatever else. Doesn't really matter how you name
> it. But it has to be defined globally and be tied with udev with the RPM
> requirements.

OK for the packages. But I meant 'What's your suggestion for a better
place to define the input group ?'

If we use a specific package to define the udev rule
(udev-global-policy.rpm or udev-profile-policy.rpm depending on profile
specificities), perhaps it makes sense to create the system user/group
in the same package ? At least, it would be consistent.


More information about the Dev mailing list