NOTE: The purpose of the "input" group is similar to purpose of groups like "audio", "video", "disk", "dialout", ..., but there's no need for a specific number. You can simply pick the first free ID from a safe range where no possible collision with other distributions can be expected. There's a small chance that other distributions will adopt this ID number in future.

This request is a little out of the ordinary as the groups that are similar are hard static allocations rather than soft static allocations. We had some questions we wanted to have answered to better understand the requirements here:

• Is the group just for device file ownership? (It seems like that would be local to the system it's on).
• Is there some other reason the gid needs to be shared between systems?
• You ask for an id that has no possible collision with other distributions. There's no available ids that would meet that expectation. Why do you think you need that and is there a problem that that's not possible?

• Is the group just for device file ownership? (It seems like that would be local to the system it's on).

Yes it is. However I can also imagine cases where reading the inputs remotely might be needed in future and in that case a commonly used static allocation could play a nice role.

• Is there some other reason the gid needs to be shared between systems?

Hope I've answered that above.

• You ask for an id that has no possible collision with other distributions. There's no available ids that would meet that expectation. Why do you think you need that and is there a problem that that's not possible?

That was just a 'nice to have' expectation. If that isn't easily possible, then pick one that seems to have the lowest probability of collisions.

Thanks in advance.

Replying to [comment:3 jcapik]:

• Is the group just for device file ownership? (It seems like that would be local to the system it's on).

Yes it is. However I can also imagine cases where reading the inputs remotely might be needed in future and in that case a commonly used static allocation could play a nice role.

Can you tell us why the GID would have to be used in this case rather than the group name?

• You ask for an id that has no possible collision with other distributions. There's no available ids that would meet that expectation. Why do you think you need that and is there a problem that that's not possible?

That was just a 'nice to have' expectation. If that isn't easily possible, then pick one that seems to have the lowest probability of collisions.

<nod> Note that there is no id number that has a low probability of collisions. http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 shows that only GIDs 0-99 and 60000-64999 have predictable assignments. Fedora and RHEL5/6 has already used up its 0-99 hard static range. Fedora chose to add an additional range 100-200 for additional static allocations. This was not picked up by RHEL5/6. There's no static gid that we can choose that won't conflict on RHEL5/6 and Debian. Once RHEL7 is out we might be able to choose an id that doesn't conflict between Fedora and RHEL7 but it will still collide with those other major distributions.

Replying to [comment:4 toshio]:

Can you tell us why the GID would have to be used in this case rather than the group name?

Accessing the devices remotely would need an additional software layer for GID tranlations (a similar one that's implemented in NFS and samba) and it's usually an unpleasant complication for admins to configure translations between two systems, not mentioning situations when you have more than two systems with different IDs. That can easily become a nightmare.

<nod> Note that there is no id number that has a low probability of collisions. http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 shows that only GIDs 0-99 and 60000-64999 have predictable assignments. Fedora and RHEL5/6 has already used up its 0-99 hard static range. Fedora chose to add an additional range 100-200 for additional static allocations. This was not picked up by RHEL5/6. There's no static gid that we can choose that won't conflict on RHEL5/6 and Debian. Once RHEL7 is out we might be able to choose an id that doesn't conflict between Fedora and RHEL7 but it will still collide with those other major distributions.

In that case it should be ok to pick one from the 100-200 range and give it few years to settle down. We might eventually ask for a change or removal if we encounter any problems (or if it doesn't serve its purpose) so that it isn't wasted for no reason.

Thank you.

Replying to [comment:5 jcapik]:

Replying to [comment:4 toshio]:

Can you tell us why the GID would have to be used in this case rather than the group name?

Accessing the devices remotely would need an additional software layer for GID tranlations (a similar one that's implemented in NFS and samba) and it's usually an unpleasant complication for admins to configure translations between two systems, not mentioning situations when you have more than two systems with different IDs. That can easily become a nightmare.

What would access these devices remotely, for what purpose and over what protocols?

Using group names instead of group id's seems like a pretty sane thing to mandate for new things in 2014.

Hello James.

The idea of input sharing was intended to be based on fifo redirected devices shared via commonly used file sharing protocols, but it was based on unverified presumptions. According to several web pages I've read, the named fifo sharing should be possible (or at least it was in the past ... smb 3.5.9, nfsv4/kernel-2.5 ), but after doing some tests here, it seems the fifo data don't pass through with the current versions of daemons/kernel. Maybe it's a matter of configuration only, but I had not enough time to do a deeper analysis yet. My comments weren't based on an already invented software and its needs, but I wanted to be sure we won't prevent us or anyone else from inventing new interesting usecases. In the past I had to configure a presentation workstation with multiple locations where the presenters could control it remotely from and I had to use VNC for that kind of task. But we experienced several issues. Available VNC solutions support "ViewOnly" mode, but do not support something like "InputOnly" mode. The input events are always translated/indirect and limited to the remote/local screen size. This can be a problem when the local screen size is lower than the remote screen size. Direct sharing via fifos would be pretty simple and with the lowest possible network traffic. It wouldn't need a display on the local side at all. However this would require a working fifo sharing mechanism first and someone, who could spend some time investigating why it didn't work during the tests.
We currently need the new "input" group for resolving svgalib permission problems, but in this scenario it doesn't need to be shared across the systems. We just wanted to cover all possible future scenarios the new "input" group could be possibly used for.

It seems to me, the problem of lack of free IDs for static allocations is a bit exaggerated. The definition of gid ranges doesn't need to match the Debian policy so strictly. Especially the higher gid ranges can be shrunk without worries so that there's enough free space for new static allocations. However, if you believe, that static allocations are strongly unwanted, then let it go. We'll have to deal with it in a different way.

Anyway, thanks for your time.

Regards,
Jaromir.

I'm afraid we're not clear about how sharing of the devices across systems and why that would use the uid/gid instead of username/groupnames works so at this time this would be unlikely to pass. If you'd like to add some more information about that we could consider that and revote.

If you're happy to use a dynamic gid for now, that's entirely fine as well. You (or we) can close this ticket if that's the case.