Propose to allocate uids from the maximum down

[lnussel]

Suggestion by Jan Engelhardt to avoid clashes with existing deployments:
http://lists.opensuse.org/opensuse-factory/2015-04/msg00336.html

• General Comment
• This needs discussion at the Wednesday weekly call, or on the mailing list
• so was this discussed or is anything needed from my side?
• The matter did not have a corresponding bug in our Bugzilla, and indeed, the question of adding a FHS specific part of the bugzilla had been pending literally for years, and so dropped out of mind. Also, with the Christmas / New Years season. the matter has not yet been discussed in the weekly call. I'll try to remember to bring this matter, ans well as
  https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=154
  up tomorrow
• any outcome?
• We discussed during yesterday's call -- bottom line was that we will add reviewing open github pull requests to the weekly Friday IRC meeting -- 10 am US ET, and probably add a process where we also create a tracking bug in our formal bugzilla, to make sure stakeholders who follow that way are alerted to go 'see the request'.
  We have not yet hit the merits of the proposal
• A few thoughts:

• How does changing the allocation range fix the problem mentioned in the thread? The theory behind Debian's range was that it was likely safe to use. Why would this new range be any safer?
• Has anyone besides SUSE signed on to the idea? I'm nervous about trying to mandate something without some cross-distro buy-in.

• It's a proposal, nobody has signed up for anything yet. The explanation for changing the proposal to a top down approach is here: https://lists.opensuse.org/opensuse-factory/2015-04/msg00249.html
• I suppose I'm not convinced by the argument that some systems have 60,000 or more users. If you're running a system like that, changing the regular user UID range to, say, 131072 and up is going to be only the first, and probably easiest, change you're going to need to make.
  This would be a lot less controversial to me if you weren't asking us to go to Debian and tell them to change their well-established policy without a serious argument that their policy is technically wrong. Frankly, I doubt that would hold water.
  Fedora's policy is different, but does arguably have a problem in that the space below 200 is a lot more constrained, so they would probably do well to consider switching to Debian's policy. And, to my knowledge, no one else has a policy to compete with Debian's.
  If you think there is a good technical argument here, then make that argument with Debian, and come back if you can get them to agree. Otherwise, I don't think this is the right approach.
• Do you know who to contact on Debian side?
• Probably the best place to discuss such things for Debian is the debian-policy mailing list:
  https://lists.debian.org/debian-policy/
  If I may make a suggestion: be sure to bring some folks along for the ride at SUSE or elsewhere that want this to happen. I think they would be more likely to be receptive if they think this is a serious proposal from SUSE, as opposed to some guy's bright idea.

[herrold]

This needs discussion at the Wednesday weekly call, or on the mailing list

[lnussel]

so was this discussed or is anything needed from my side?

[herrold]

The matter did not have a corresponding bug in our Bugzilla, and indeed, the question of adding a FHS specific part of the bugzilla had been pending literally for years, and so dropped out of mind. Also, with the Christmas / New Years season. the matter has not yet been discussed in the weekly call. I'll try to remember to bring this matter, ans well as
https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=154

up tomorrow

[lnussel]

any outcome?

[herrold]

We discussed during yesterday's call -- bottom line was that we will add reviewing open github pull requests to the weekly Friday IRC meeting -- 10 am US ET, and probably add a process where we also create a tracking bug in our formal bugzilla, to make sure stakeholders who follow that way are alerted to go 'see the request'.

We have not yet hit the merits of the proposal

[licquia]

A few thoughts:

• How does changing the allocation range fix the problem mentioned in the thread? The theory behind Debian's range was that it was likely safe to use. Why would this new range be any safer?
• Has anyone besides SUSE signed on to the idea? I'm nervous about trying to mandate something without some cross-distro buy-in.

[lnussel]

It's a proposal, nobody has signed up for anything yet. The explanation for changing the proposal to a top down approach is here: https://lists.opensuse.org/opensuse-factory/2015-04/msg00249.html

[licquia]

I suppose I'm not convinced by the argument that some systems have 60,000 or more users. If you're running a system like that, changing the regular user UID range to, say, 131072 and up is going to be only the first, and probably easiest, change you're going to need to make.

This would be a lot less controversial to me if you weren't asking us to go to Debian and tell them to change their well-established policy without a serious argument that their policy is technically wrong. Frankly, I doubt that would hold water.

Fedora's policy is different, but does arguably have a problem in that the space below 200 is a lot more constrained, so they would probably do well to consider switching to Debian's policy. And, to my knowledge, no one else has a policy to compete with Debian's.

If you think there is a good technical argument here, then make that argument with Debian, and come back if you can get them to agree. Otherwise, I don't think this is the right approach.

[lnussel]

Do you know who to contact on Debian side?

[licquia]

Probably the best place to discuss such things for Debian is the debian-policy mailing list:

https://lists.debian.org/debian-policy/

If I may make a suggestion: be sure to bring some folks along for the ride at SUSE or elsewhere that want this to happen. I think they would be more likely to be receptive if they think this is a serious proposal from SUSE, as opposed to some guy's bright idea.