Re: Package-created usernames
So here's a straw man draft for a decision on package-created usernames: -8- RUBRIC 1. We exercise our power in Constitution 6.1(1) to specify the contents of Debian policy documents, and that in 6.1(5) to offer our opinion. 2. Maintainers of policy documents should consult in their usual way on the detailed wording(s) needed to give effect to our decision, and must then make changes to policy accordingly. 3. Debian package maintainers should implement our decision immediately where practical. PUBLIC NOTICE 4. Debian hereby claims the portion of the username and groupname namespaces which consist of names starting with a capital letter D. Such names are `Debian user and group names'. 5. Debian names are allocated by Debian Developers. Everyone is encouraged to use the Debian name consistently with the way it is used in the Debian package(s) and the corresponding Debian documentation (whether in official Debian policy or in individual packages). Everyone is strongly discouraged from using Debian names in any other waay. 6. Non-Debian Free Software developers who need a reserved username for some purpose are invited to contact Debian (at the time of writing, via the debian-policy mailing list). DEBIAN PACKAGING 7. It is best if usernames and groupnames (`names', henceforth) used by packages are easy to change. Maintainers should bear this in mind, and should consider make names configurable if this does not cause other problems. 9. Individual names used by Debian packages should be Debian names, documented appropriately if the usage is not obvious. The names currently in base-files are an exception but none more should be added. Packages where the username is hard to change, or where it cannot be changed without rebuilding the package, must use a Debian naame. 9. Debian packages should not claim any other large sections of the namespace. Conventions such as S at the start of SLIP account names are useful but the user must be able to configure and override these in case it conflicts with local policy. 10. All software in Debian should cope with names starting with uppercase letters. Such users and groups should be treated as system users and groups; for example, mail should not be accepted for them by default. 11. Names are generally case-sensitive and their case should be preserved. Where names occur in contexts defined as case-insensitive by external standards (for example the DNS) maintainers should consider whether system users should appear in the external namespace at all. Simply case-smashing names is always forbidden since a system may have names which differ only in case but which are very different users or groups. -8- Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package-created usernames
Bdale Garbee writes (Re: Package-created usernames): After digesting the replies here and some off-list discussions, I now agree that while it is desireable for packages to be flexible about usernames to support the kinds of situations I described, requiring all Debian packages to be flexible in this way is not a reasonable objective. Right, and I certainly agree that username flexibility ought to be encouraged. Usernames shouldn't be compiled in and unchangeable by local configuration without some good reason. But in the cases where there is such a good reason (which is a decision of the kind we usually expect package maintainers to make), how should that username be chosen ? If we can come up with a good answer to that question (I think the suggestions we've had so far show that we can), surely we should use it even where the package can in principle be reconfigured. After all that still saves admins the work of reconfiguring one side of the name clash. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package-created usernames
[EMAIL PROTECTED] (Florian Weimer) writes: * Bdale Garbee: The second is whether it's acceptable for a Debian package to *require* a specific username. There are a couple of setuid binaries which might have problems switching to a more flexible scheme. I fear such a requirement might actually reduce overall security. Right. After digesting the replies here and some off-list discussions, I now agree that while it is desireable for packages to be flexible about usernames to support the kinds of situations I described, requiring all Debian packages to be flexible in this way is not a reasonable objective. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package-created usernames
* Bdale Garbee: The second is whether it's acceptable for a Debian package to *require* a specific username. There are a couple of setuid binaries which might have problems switching to a more flexible scheme. I fear such a requirement might actually reduce overall security. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package-created usernames
Bdale Garbee writes (Re: Package-created usernames): The second is whether it's acceptable for a Debian package to *require* a specific username. There seems to be at least an implication that if the namespace clash potential is eliminated or significantly reduced, that this would remove the need for supporting configurability of the username used by a package or set of packages. I'm very concerned about this, since I believe that no matter how well we solve the namespace potential collision problem, there will always be users of our packages in large installation environments who have already made decisions about their username namespace that they want Debian systems to be able to fit in to without requiring rework or recompilation of packages. I can see your point but I think it is in general impractical to require programs not to have compiled-in usernames. A great many of our standard daemons work that way. If we choose a `sufficiently good' naming scheme then I think problems are very unlikely. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package-created usernames
[EMAIL PROTECTED] (Ian Jackson) writes: I think we probably have enough bandwidth (or will do shortly) to take on another item from our todo list. #429671 on username policy seems to me to be where we can most obviously improve the situation so I'm going to start there. I believe this bug report actually embodies two issues, which we probably need to think about (and perhaps even rule on?) independently. The first is the obvious question of naming policy, which I've frankly spent less time thinking about, but which your note should certainly help launch some discussion on. The second is whether it's acceptable for a Debian package to *require* a specific username. There seems to be at least an implication that if the namespace clash potential is eliminated or significantly reduced, that this would remove the need for supporting configurability of the username used by a package or set of packages. I'm very concerned about this, since I believe that no matter how well we solve the namespace potential collision problem, there will always be users of our packages in large installation environments who have already made decisions about their username namespace that they want Debian systems to be able to fit in to without requiring rework or recompilation of packages. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package-created usernames
On Tue, Dec 04, 2007 at 08:52:34PM -0700, Bdale Garbee wrote: The second is whether it's acceptable for a Debian package to *require* a specific username. There seems to be at least an implication that if the namespace clash potential is eliminated or significantly reduced, that this would remove the need for supporting configurability of the username used by a package or set of packages. I'm very concerned about this, since I believe that no matter how well we solve the namespace potential collision problem, there will always be users of our packages in large installation environments who have already made decisions about their username namespace that they want Debian systems to be able to fit in to without requiring rework or recompilation of packages. CAN OF WORMS DANGER AHEAD! BEWARE! The user name is likely to be spread out through build-time, installation-time and run-time scripts in the package. Since one cannot easily build includes in maintainer scripts, one would probably need to _generate_ the maintainer scripts at package build time, introducing gazillions of interesting bugs. Please, don't open that can of worms, and settle on a naming policy which minimizes impact, such as the Debian- prefix that Debian's default MTA has been using for years. I am sure that we'd know by now if this had made trouble anywhere. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package-created usernames
I think we probably have enough bandwidth (or will do shortly) to take on another item from our todo list. #429671 on username policy seems to me to be where we can most obviously improve the situation so I'm going to start there. The problem which Marc Haber (Exim maintainer) is trying to solve is the possibility of username clashes between usernames chosen by package maintainers for use by those packages, and usernames chosen by users and administrators (both for human beings and for local use). I agree with Marc that this is a problem which we ought at least to try to solve. In particular, because: 1. It is not always easy to avoid being bitten by this problem. Because there is no global (really global!) registry of reserved usernames, it is quite possible for a site administrator and a Debian package maintainer to allocate the same username without either of them necessarily being at fault. 2. When a clash does occur the consequences can be very severe for the affected site. The only effective options available to the administrator are (a) to change the username of the locally allocated user, which is in many environments a very serious undertaking. It is likely to be technically and politically awkward and cause ongoing problems (because usernames are stored not just in computers but also in the minds of people). I have personal experience of changing usernames on my colo system and it's quite hard work. (b) to permanently maintain a fork of the Debian package(s) in question (or perhaps if they're lucky just deal with configuration file conflicts forever more). Often an actual fork will be needed because many programs have usernames compiled in. (c) not to install the packages and to use something different (eg, a different operating system). (d) to persuade the Debian maintainer to change the name (which is likely to be very difficult). All of these are very unattractive. 3. The solution, to divide up the namespace, is fairly straightforward. The only deficiencies of this approach are (a) that some people might consider the names from the new Debian-reserved namespace somewhat ugly (b) the new names might be somewhat longer. Some people may argue that the new names may break existing software but this is known not to be the case. Debian's Exim packages have been using long names with capital letters for some time now without serious problems - the only glitch I'm aware of personally is that the very long names involved aren't always displayed in the most ideal manner. I have been giving special-purpose accounts names starting with specific capital letters (for example, I independently invented S* for Slip accounts) on chiark for years and it works well. It might be argued that it is too disruptive to change all the packages' reserved names. However, that is a separate question: it would be quite possible to grandfather some subset of the already-allocated names and merely solve the problem for names allocated in the future. The only question remaining to be decided is what the form of the new names ought to be. I would lean towards choosing a representation which allows us to continue to use short names for system accounts. DJB's proposal of an initial capital letter has some merit, and it seems that the obvious choice would be `D' for names allocated by Debian. The remainder of the name should consist of no more than 7 lowercase alphanumerics. An additional advantage to using a capital letter is that there are already many programs which do not treat users with capital letters as `real' users. For example, Exim itself in a usual configuration will ignore passwd file entries which are not lowercase, because it lowercases usernames before looking them up. On the question of grandfathering, I would suggest that we explicitly bless at least - the commonly-known UNIX user and group names (someone should go through base-files and check the list there) - existing packages already using names with capital letters in them Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
