├── Contributing.txt ├── LICENSE ├── README.md ├── documents └── wip │ └── userNaming.txt ├── specification.tmpl └── tests └── distro ├── groupNames.py └── userNames.py /Contributing.txt: -------------------------------------------------------------------------------- 1 | Contributing is easy, just fork the project on Github and send a pull-request 2 | when your changes are ready. 3 | 4 | The core technical team of the LSB working group will review the pull request 5 | and once agreement is reached (2 or more +1) the request will be merged. The 6 | core technical team with repository commit access will abide by the same rules, 7 | i.e. members with commit access will send pull requests to allow public review 8 | of proposed changes. 9 | 10 | The repository is structured into two major categories, documents and tests. 11 | The documents directory is structured to follow the work flow, problem 12 | statement -> proposed solution -> solution, the details are outlined below. The 13 | testing directory is structured to differentiate tests to their applicability, 14 | for example an interface test for glibc would be found in tests/glibc and 15 | tests that address distribution concerns, such as identifying the vendor are 16 | located in tests/distro. 17 | 18 | documents/wip 19 | - contains text files following the template (specification.tmpl) with 20 | at least a completed Problem Statement section. 21 | - the documents describe a problem that affects many or all distributions 22 | and makes it difficult to treat the distributions as one platform from 23 | an ISV developer or administrative point of view. Differences in packaging 24 | generally do not fall into this category. 25 | 26 | documents/specifications 27 | - contains text files following the template (specification.tmpl) with 28 | a completed Problem Statement and a completed Solution section. 29 | - the documents describe the consensus solution to the problem statement. 30 | In most cases the "Proposed Solution" section can be renamed to 31 | "Solution". The links to the mailing list discussions during the proposal 32 | phase are to remain. 33 | - contains a list of distributions that have pledged to abide by this 34 | specification and integrate the appropriate unit test into their QA suite 35 | - contains the name(s) of the tests verifying the solution implementation. 36 | 37 | tests/distro 38 | - contains tests that verify distribution level specifications, such as 39 | the identification of the distribution vendor. 40 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | GNU GENERAL PUBLIC LICENSE 2 | Version 2, June 1991 3 | 4 | Copyright (C) 1989, 1991 Free Software Foundation, Inc., 5 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA 6 | Everyone is permitted to copy and distribute verbatim copies 7 | of this license document, but changing it is not allowed. 8 | 9 | Preamble 10 | 11 | The licenses for most software are designed to take away your 12 | freedom to share and change it. By contrast, the GNU General Public 13 | License is intended to guarantee your freedom to share and change free 14 | software--to make sure the software is free for all its users. This 15 | General Public License applies to most of the Free Software 16 | Foundation's software and to any other program whose authors commit to 17 | using it. (Some other Free Software Foundation software is covered by 18 | the GNU Lesser General Public License instead.) You can apply it to 19 | your programs, too. 20 | 21 | When we speak of free software, we are referring to freedom, not 22 | price. Our General Public Licenses are designed to make sure that you 23 | have the freedom to distribute copies of free software (and charge for 24 | this service if you wish), that you receive source code or can get it 25 | if you want it, that you can change the software or use pieces of it 26 | in new free programs; and that you know you can do these things. 27 | 28 | To protect your rights, we need to make restrictions that forbid 29 | anyone to deny you these rights or to ask you to surrender the rights. 30 | These restrictions translate to certain responsibilities for you if you 31 | distribute copies of the software, or if you modify it. 32 | 33 | For example, if you distribute copies of such a program, whether 34 | gratis or for a fee, you must give the recipients all the rights that 35 | you have. You must make sure that they, too, receive or can get the 36 | source code. And you must show them these terms so they know their 37 | rights. 38 | 39 | We protect your rights with two steps: (1) copyright the software, and 40 | (2) offer you this license which gives you legal permission to copy, 41 | distribute and/or modify the software. 42 | 43 | Also, for each author's protection and ours, we want to make certain 44 | that everyone understands that there is no warranty for this free 45 | software. If the software is modified by someone else and passed on, we 46 | want its recipients to know that what they have is not the original, so 47 | that any problems introduced by others will not reflect on the original 48 | authors' reputations. 49 | 50 | Finally, any free program is threatened constantly by software 51 | patents. We wish to avoid the danger that redistributors of a free 52 | program will individually obtain patent licenses, in effect making the 53 | program proprietary. To prevent this, we have made it clear that any 54 | patent must be licensed for everyone's free use or not licensed at all. 55 | 56 | The precise terms and conditions for copying, distribution and 57 | modification follow. 58 | 59 | GNU GENERAL PUBLIC LICENSE 60 | TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 61 | 62 | 0. This License applies to any program or other work which contains 63 | a notice placed by the copyright holder saying it may be distributed 64 | under the terms of this General Public License. The "Program", below, 65 | refers to any such program or work, and a "work based on the Program" 66 | means either the Program or any derivative work under copyright law: 67 | that is to say, a work containing the Program or a portion of it, 68 | either verbatim or with modifications and/or translated into another 69 | language. (Hereinafter, translation is included without limitation in 70 | the term "modification".) Each licensee is addressed as "you". 71 | 72 | Activities other than copying, distribution and modification are not 73 | covered by this License; they are outside its scope. The act of 74 | running the Program is not restricted, and the output from the Program 75 | is covered only if its contents constitute a work based on the 76 | Program (independent of having been made by running the Program). 77 | Whether that is true depends on what the Program does. 78 | 79 | 1. You may copy and distribute verbatim copies of the Program's 80 | source code as you receive it, in any medium, provided that you 81 | conspicuously and appropriately publish on each copy an appropriate 82 | copyright notice and disclaimer of warranty; keep intact all the 83 | notices that refer to this License and to the absence of any warranty; 84 | and give any other recipients of the Program a copy of this License 85 | along with the Program. 86 | 87 | You may charge a fee for the physical act of transferring a copy, and 88 | you may at your option offer warranty protection in exchange for a fee. 89 | 90 | 2. You may modify your copy or copies of the Program or any portion 91 | of it, thus forming a work based on the Program, and copy and 92 | distribute such modifications or work under the terms of Section 1 93 | above, provided that you also meet all of these conditions: 94 | 95 | a) You must cause the modified files to carry prominent notices 96 | stating that you changed the files and the date of any change. 97 | 98 | b) You must cause any work that you distribute or publish, that in 99 | whole or in part contains or is derived from the Program or any 100 | part thereof, to be licensed as a whole at no charge to all third 101 | parties under the terms of this License. 102 | 103 | c) If the modified program normally reads commands interactively 104 | when run, you must cause it, when started running for such 105 | interactive use in the most ordinary way, to print or display an 106 | announcement including an appropriate copyright notice and a 107 | notice that there is no warranty (or else, saying that you provide 108 | a warranty) and that users may redistribute the program under 109 | these conditions, and telling the user how to view a copy of this 110 | License. (Exception: if the Program itself is interactive but 111 | does not normally print such an announcement, your work based on 112 | the Program is not required to print an announcement.) 113 | 114 | These requirements apply to the modified work as a whole. If 115 | identifiable sections of that work are not derived from the Program, 116 | and can be reasonably considered independent and separate works in 117 | themselves, then this License, and its terms, do not apply to those 118 | sections when you distribute them as separate works. But when you 119 | distribute the same sections as part of a whole which is a work based 120 | on the Program, the distribution of the whole must be on the terms of 121 | this License, whose permissions for other licensees extend to the 122 | entire whole, and thus to each and every part regardless of who wrote it. 123 | 124 | Thus, it is not the intent of this section to claim rights or contest 125 | your rights to work written entirely by you; rather, the intent is to 126 | exercise the right to control the distribution of derivative or 127 | collective works based on the Program. 128 | 129 | In addition, mere aggregation of another work not based on the Program 130 | with the Program (or with a work based on the Program) on a volume of 131 | a storage or distribution medium does not bring the other work under 132 | the scope of this License. 133 | 134 | 3. You may copy and distribute the Program (or a work based on it, 135 | under Section 2) in object code or executable form under the terms of 136 | Sections 1 and 2 above provided that you also do one of the following: 137 | 138 | a) Accompany it with the complete corresponding machine-readable 139 | source code, which must be distributed under the terms of Sections 140 | 1 and 2 above on a medium customarily used for software interchange; or, 141 | 142 | b) Accompany it with a written offer, valid for at least three 143 | years, to give any third party, for a charge no more than your 144 | cost of physically performing source distribution, a complete 145 | machine-readable copy of the corresponding source code, to be 146 | distributed under the terms of Sections 1 and 2 above on a medium 147 | customarily used for software interchange; or, 148 | 149 | c) Accompany it with the information you received as to the offer 150 | to distribute corresponding source code. (This alternative is 151 | allowed only for noncommercial distribution and only if you 152 | received the program in object code or executable form with such 153 | an offer, in accord with Subsection b above.) 154 | 155 | The source code for a work means the preferred form of the work for 156 | making modifications to it. For an executable work, complete source 157 | code means all the source code for all modules it contains, plus any 158 | associated interface definition files, plus the scripts used to 159 | control compilation and installation of the executable. However, as a 160 | special exception, the source code distributed need not include 161 | anything that is normally distributed (in either source or binary 162 | form) with the major components (compiler, kernel, and so on) of the 163 | operating system on which the executable runs, unless that component 164 | itself accompanies the executable. 165 | 166 | If distribution of executable or object code is made by offering 167 | access to copy from a designated place, then offering equivalent 168 | access to copy the source code from the same place counts as 169 | distribution of the source code, even though third parties are not 170 | compelled to copy the source along with the object code. 171 | 172 | 4. You may not copy, modify, sublicense, or distribute the Program 173 | except as expressly provided under this License. Any attempt 174 | otherwise to copy, modify, sublicense or distribute the Program is 175 | void, and will automatically terminate your rights under this License. 176 | However, parties who have received copies, or rights, from you under 177 | this License will not have their licenses terminated so long as such 178 | parties remain in full compliance. 179 | 180 | 5. You are not required to accept this License, since you have not 181 | signed it. However, nothing else grants you permission to modify or 182 | distribute the Program or its derivative works. These actions are 183 | prohibited by law if you do not accept this License. Therefore, by 184 | modifying or distributing the Program (or any work based on the 185 | Program), you indicate your acceptance of this License to do so, and 186 | all its terms and conditions for copying, distributing or modifying 187 | the Program or works based on it. 188 | 189 | 6. Each time you redistribute the Program (or any work based on the 190 | Program), the recipient automatically receives a license from the 191 | original licensor to copy, distribute or modify the Program subject to 192 | these terms and conditions. You may not impose any further 193 | restrictions on the recipients' exercise of the rights granted herein. 194 | You are not responsible for enforcing compliance by third parties to 195 | this License. 196 | 197 | 7. If, as a consequence of a court judgment or allegation of patent 198 | infringement or for any other reason (not limited to patent issues), 199 | conditions are imposed on you (whether by court order, agreement or 200 | otherwise) that contradict the conditions of this License, they do not 201 | excuse you from the conditions of this License. If you cannot 202 | distribute so as to satisfy simultaneously your obligations under this 203 | License and any other pertinent obligations, then as a consequence you 204 | may not distribute the Program at all. For example, if a patent 205 | license would not permit royalty-free redistribution of the Program by 206 | all those who receive copies directly or indirectly through you, then 207 | the only way you could satisfy both it and this License would be to 208 | refrain entirely from distribution of the Program. 209 | 210 | If any portion of this section is held invalid or unenforceable under 211 | any particular circumstance, the balance of the section is intended to 212 | apply and the section as a whole is intended to apply in other 213 | circumstances. 214 | 215 | It is not the purpose of this section to induce you to infringe any 216 | patents or other property right claims or to contest validity of any 217 | such claims; this section has the sole purpose of protecting the 218 | integrity of the free software distribution system, which is 219 | implemented by public license practices. Many people have made 220 | generous contributions to the wide range of software distributed 221 | through that system in reliance on consistent application of that 222 | system; it is up to the author/donor to decide if he or she is willing 223 | to distribute software through any other system and a licensee cannot 224 | impose that choice. 225 | 226 | This section is intended to make thoroughly clear what is believed to 227 | be a consequence of the rest of this License. 228 | 229 | 8. If the distribution and/or use of the Program is restricted in 230 | certain countries either by patents or by copyrighted interfaces, the 231 | original copyright holder who places the Program under this License 232 | may add an explicit geographical distribution limitation excluding 233 | those countries, so that distribution is permitted only in or among 234 | countries not thus excluded. In such case, this License incorporates 235 | the limitation as if written in the body of this License. 236 | 237 | 9. The Free Software Foundation may publish revised and/or new versions 238 | of the General Public License from time to time. Such new versions will 239 | be similar in spirit to the present version, but may differ in detail to 240 | address new problems or concerns. 241 | 242 | Each version is given a distinguishing version number. If the Program 243 | specifies a version number of this License which applies to it and "any 244 | later version", you have the option of following the terms and conditions 245 | either of that version or of any later version published by the Free 246 | Software Foundation. If the Program does not specify a version number of 247 | this License, you may choose any version ever published by the Free Software 248 | Foundation. 249 | 250 | 10. If you wish to incorporate parts of the Program into other free 251 | programs whose distribution conditions are different, write to the author 252 | to ask for permission. For software which is copyrighted by the Free 253 | Software Foundation, write to the Free Software Foundation; we sometimes 254 | make exceptions for this. Our decision will be guided by the two goals 255 | of preserving the free status of all derivatives of our free software and 256 | of promoting the sharing and reuse of software generally. 257 | 258 | NO WARRANTY 259 | 260 | 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY 261 | FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN 262 | OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES 263 | PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED 264 | OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 265 | MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS 266 | TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE 267 | PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, 268 | REPAIR OR CORRECTION. 269 | 270 | 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING 271 | WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR 272 | REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, 273 | INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING 274 | OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED 275 | TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY 276 | YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 277 | PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE 278 | POSSIBILITY OF SUCH DAMAGES. 279 | 280 | END OF TERMS AND CONDITIONS 281 | 282 | How to Apply These Terms to Your New Programs 283 | 284 | If you develop a new program, and you want it to be of the greatest 285 | possible use to the public, the best way to achieve this is to make it 286 | free software which everyone can redistribute and change under these terms. 287 | 288 | To do so, attach the following notices to the program. It is safest 289 | to attach them to the start of each source file to most effectively 290 | convey the exclusion of warranty; and each file should have at least 291 | the "copyright" line and a pointer to where the full notice is found. 292 | 293 | {description} 294 | Copyright (C) {year} {fullname} 295 | 296 | This program is free software; you can redistribute it and/or modify 297 | it under the terms of the GNU General Public License as published by 298 | the Free Software Foundation; either version 2 of the License, or 299 | (at your option) any later version. 300 | 301 | This program is distributed in the hope that it will be useful, 302 | but WITHOUT ANY WARRANTY; without even the implied warranty of 303 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 304 | GNU General Public License for more details. 305 | 306 | You should have received a copy of the GNU General Public License along 307 | with this program; if not, write to the Free Software Foundation, Inc., 308 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 309 | 310 | Also add information on how to contact you by electronic and paper mail. 311 | 312 | If the program is interactive, make it output a short notice like this 313 | when it starts in an interactive mode: 314 | 315 | Gnomovision version 69, Copyright (C) year name of author 316 | Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 317 | This is free software, and you are welcome to redistribute it 318 | under certain conditions; type `show c' for details. 319 | 320 | The hypothetical commands `show w' and `show c' should show the appropriate 321 | parts of the General Public License. Of course, the commands you use may 322 | be called something other than `show w' and `show c'; they could even be 323 | mouse-clicks or menu items--whatever suits your program. 324 | 325 | You should also get your employer (if you work as a programmer) or your 326 | school, if any, to sign a "copyright disclaimer" for the program, if 327 | necessary. Here is a sample; alter the names: 328 | 329 | Yoyodyne, Inc., hereby disclaims all copyright interest in the program 330 | `Gnomovision' (which makes passes at compilers) written by James Hacker. 331 | 332 | {signature of Ty Coon}, 1 April 1989 333 | Ty Coon, President of Vice 334 | 335 | This General Public License does not permit incorporating your program into 336 | proprietary programs. If your program is a subroutine library, you may 337 | consider it more useful to permit linking proprietary applications with the 338 | library. If this is what you want to do, use the GNU Lesser General 339 | Public License instead of this License. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | LSB 2 | === 3 | 4 | Linux Standard Base Documentation and Tests 5 | 6 | The Linux Standard Base working group is a working group presently under the 7 | umbrella of the Linux Foundation. 8 | 9 | For many years the working group has spent its time focusing on the 10 | production of the LSB specification which consists of a formal written 11 | specification, similar to IEEE or ISO standards, and an accompanying test 12 | suite. The test suite was focused on certification testing of distributions 13 | and as such had an easy to use LSB specific test framework. 14 | 15 | The specification was historically defined as a 'trailing' specification 16 | to document an accepted cross section of packages, libraries, and interfaces 17 | in Linux distributions. Linux distribution development happens at various 18 | rates ranging from a 6 month release cycle at the short end to multi year 19 | release cycles at the long end of the time scale. Distributions with the 20 | longer release cycle are generally more interested in long term stability 21 | and as such had become the primary target of the LSB specification. 22 | 23 | As the commercial "Linux market" has matured the specification and tests 24 | have contributed to maintaining a certain compatibility across Linux 25 | distributions making it reasonably straight forward for ISVs to treat many 26 | distributions as one Linux platform. At the same time with the market 27 | acceptance and adoption of Open Source software, Agile rapid development 28 | models, and Test Driven Design, a demand has appeared for new interfaces. 29 | The speed at which these interfaces have been adopted by Linux distributions 30 | has significantly increased such that the creation of a formal specification 31 | and accompanying certification is no longer as important a primary goal. 32 | 33 | Therefore, at the face to face meeting held during the Linux Foundation 34 | Collaboration Summit in March, 2014, the working group has concluded that 35 | rather than producing a voluminous specification, the working group should 36 | transform its work to emphasize its other role as a neutral venue to discuss 37 | and resolve cross-distribution topics that are important to ISVs and 38 | distributors. This new focus will allow the working group to continue to 39 | provide the value of contributing to distribution compatibility while at the 40 | same time being more involved in cross-distribution discussions. 41 | 42 | The LSB 5.0 specification released in 2014 may well be the last of 43 | its kind. The specification and tests are in maintenance mode. Bugs will be 44 | accepted and fixed and these bug fixes may be released as updates, 45 | i.e. 5.0.1 and others as needed. However, we do not presently plan to work 46 | new major LSB specification releases such as LSB 5.1 or 6.0. 47 | The specification and accompanying tests remain in the Bazaar 48 | tree ( http://bzr.linuxfoundation.org/loggerhead/lsb/ ) maintained by the 49 | working group. No new development, i.e. large scale addition of new 50 | interfaces, libraries, etc., is expected in the Bazaar repository. That 51 | repository will be quiesced as to new commits, and parts may be replicated 52 | to the GitHub Linux Standard Base project. 53 | 54 | The focus on providing distribution compatibility, where it matters to 55 | distributions, ISVs, and other stakeholders will remain a key goal of the 56 | working group. The approach to the compatibility challenge is that a specific 57 | challenge will be described in a reasonably short document along with a 58 | solution. Once a solution is accepted by a number of distributions it becomes 59 | a de facto standard. Where ever possible one or more tests are to be 60 | implemented that allow distributions to test their compliance to the agreed 61 | upon specification. Distributions that pledge to support the agreed upon 62 | solution are listed in the document containing the problem statement and 63 | agreed upon solution. 64 | 65 | The general work flow is that a problem is identified and the problem 66 | statement is formulated. The problem identification generally happens via 67 | the issue tracker in GitHub. Once a problem statement is formulated a pull 68 | request for the document located in documents/wip should be issued. A second 69 | step is the creation of a solution proposal which may then be solicited 70 | to distributions for discussion. Once consensus is reached the solution is 71 | committed to documents/specifications without additional changes. Changes 72 | to accepted solutions should only consist of trivial fixes for spelling and 73 | grammar as well as additions of new distributions pledging to support 74 | a given specification. 75 | 76 | The solicitation of a Problem Statement or a Solution Proposal should 77 | occur on a distribution public mailing list and a link to the thread 78 | should be included in the document. 79 | 80 | Unless specifically stated no document should become an accepted 81 | specification without an accompanying test that allows distributions to self 82 | monitor their compliance to the agreed upon de facto standard. 83 | 84 | Contribution guidelines are provided in the Contributing.txt file in the 85 | top level of the repository. 86 | -------------------------------------------------------------------------------- /documents/wip/userNaming.txt: -------------------------------------------------------------------------------- 1 | LSB Specification Proposal 2 | 3 | Problem Statement: 4 | ------------------ 5 | 6 | For administrators and certain types of applications it is important to have 7 | a cross distribution consistent naming policy for system created users. In 8 | certain cases it is also important to have a consistent user and group ids 9 | (UID & GID) for system created users. 10 | 11 | The various available cloud frameworks such as OpenStack, openNebula, 12 | CloudStack, and Eucalyptus come to mind. All cloud frameworks have services 13 | running on all the nodes in a cluster that comprises the cloud on the hardware 14 | side. It is generally possible to configure image sharing in these frameworks 15 | via NFS and thus the user name, UID, and GID need to match on all installations 16 | to provide the proper access permissions. This requirement reduces to 17 | consistent user names with NFSv4, but the adoption rate of NFSv4 is unknown. 18 | Additionally services for cloud frameworks may be configured in an HA 19 | environment and may not tolerate fail-over with UID transitioning. 20 | 21 | In an environment where LDAP is used system administrators may pre-create 22 | system users through the LDAP mechanism. This is difficult if different 23 | user names and UID as well as GID implementations exist across various 24 | distributions. 25 | 26 | Last but not least system users, i.e. names created through distribution 27 | provided packages, may collide with names created for "regular" system 28 | users. A common pattern for user names on Unix systems is to combine 29 | letters of the users name, many combinations of first and last name letters 30 | are in use. This may lead to combinations that may overlap with system user 31 | names. Sharing a user name between a system user and a person user leads 32 | to surprising or even security relevant misbehavior as the daemon user 33 | may write to files in the real user's home or vice versa. 34 | 35 | A cross distribution solution will also give upstream projects an avenue to 36 | determine user names when needed and ensure that distributions are consistent 37 | eliminating one potential source of issues for upstream projects 38 | 39 | 40 | Proposed Solution: 41 | -------------------- 42 | 43 | The proposal is to adopt a consistent naming an numbering convention across 44 | Linux distributions. The proposed solution is 3 fold to address 3 distinct 45 | problems described in the Problem Statement above. 46 | 47 | 1.) Consistent grouping of system users, system users are defined as those 48 | users created by distribution packages. 49 | 2.) Create a naming convention for system users 50 | 3.) Create prescribed user IDs for specific system users that need to be 51 | consistent across distributions. 52 | 53 | 1.) It is proposed to consider using a grouping similar to the existing 54 | Debian numbering policy documented here: https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.1 . This provides the option of assigning "fixed" UIDs 55 | for those processes that need them in either the range of 1 - 99 (0 being 56 | already allocated for root) or in the 60000 - 64999 range. Although is expected 57 | that only few (famous last words) system users need a consistent UID across 58 | distributions it is probably best to allocate fixed IDs in the 60000 range to 59 | avoid interfereing with existing IDs used by various distributions in the 60 | 0-99 range. It should be up to the upstream projects or packagers of 61 | that code to make a case for a static UID/GID. 62 | 63 | Some of the current policies: 64 | 65 | Debian 66 | ------ 67 | https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.1 68 | 69 | 0-99: 70 | pre-allocated fixed uids 71 | https://anonscm.debian.org/cgit/users/cjwatson/base-passwd.git/tree/passwd.master 72 | 73 | 100-999: 74 | dynamically allocated system users 75 | 76 | 1000-59999: 77 | user accounts 78 | 79 | 60000-64999: 80 | reserved fixed uids, created on demand for 'obscure' packages. 81 | Registry of user names is here: 82 | https://anonscm.debian.org/cgit/users/cjwatson/base-passwd.git/tree/README 83 | 84 | 65000-65533: 85 | unused 86 | 87 | Fedora 88 | ------ 89 | from 90 | http://pkgs.fedoraproject.org/cgit/shadow-utils.git/tree/shadow-utils.login.defs 91 | 92 | 0-200: 93 | reserved fixed uids, most created on demand 94 | https://git.fedorahosted.org/cgit/setup.git/tree/passwd 95 | Registry: 96 | https://git.fedorahosted.org/cgit/setup.git/tree/uidgid 97 | looking at that file it seems they are running out of uids there 98 | 99 | 201-999: 100 | dynamically allocated system users 101 | 102 | 1000-60000: 103 | user accounts 104 | 105 | Gentoo 106 | ------ 107 | login.defs seems to be unmodified from shadow package 108 | 109 | 0-100: 110 | reserved fixed uids (+250 which is hardcoded to portage) 111 | https://gitweb.gentoo.org/proj/baselayout.git/tree/share.Linux/passwd 112 | Some created on demand but no central registry seems to exist 113 | 114 | 101-999: 115 | dynamically allocated system users 116 | 117 | 1000-60000: 118 | user accounts 119 | 120 | SUSE 121 | ---- 122 | from /etc/login.defs, pkg shadow 123 | 124 | 0-99: 125 | reserved fixed uids, some created on demand by packages but no 126 | registry for those 127 | 128 | 100-499: 129 | dynamically allocated system users 130 | 131 | 500-999: 132 | unused 133 | 134 | 1000-60000: 135 | user accounts 136 | 137 | 138 | Thanks to Ludwig Nussel for doing the leg work and collecting this information. 139 | The registry of users could rest with the LSB work group. 140 | 141 | 2.) We should establish a naming convention for all users created by packages. 142 | The chosen convention should diminish the collision likelihood between users 143 | created by the system administrator, i.e. "real" users and system users. In a 144 | discussion on the openSUSE list it was proposed to prefix system user names 145 | with an "_" (underscore.) This has precedence in openBSD, the proposal for 146 | this prefix and a rationale can be found here: 147 | https://github.com/lnussel/osep_opensuse_usernames/blob/master/opensuse_usernames.txt. Using "_" as a prefix appears to be a reasonable solution 148 | and thus this is nominated as the solution to adopt. 149 | 150 | 3.) Using fixed UID/GID for certain types of system users across distributions 151 | will allow users to install multiple distributions and use the distribution 152 | provided packages without having to take special care of the creation of 153 | UIDs and GIDs for these users. The primary candidates for cross distribution 154 | consistent UDS and GIDs are the known cloud frame works, CloudStack, 155 | Eucalyptus, openNebula, and OpenStack. All frameworks support storage access 156 | via NFS for image storage or may be setup in a HA environment. While NFSv4 157 | supports different UIDs/GIDs for the same user on different installations, the 158 | penetration of NFSv4 may not be sufficiently high to eliminate this need. In 159 | an HA fail over environment the potential change in UID of the user on one 160 | machine and another UID on the fail over machine may not be tolerated. It is 161 | therefore proposed that the created system users for the cloud frameworks 162 | be assigned consistent user IDs across distributions start with 99 and working 163 | down, the order is not of material interest. 164 | 165 | _oneadmin -> 60001 (system user for openNebula) 166 | _openstack -> 60002 167 | _cloudstack -> 60003 168 | _eucalyptus -> 60004 169 | 170 | Using the proposed "_" prefix for the proposed IDs for the cloud frameworks. 171 | 172 | 173 | Solution Discussion Links: 174 | -------------------------- 175 | 176 | Discussion on openSUSE-Factory ML concerning the introduction of "_" as a 177 | prefix naming convention for system users. 178 | http://lists.opensuse.org/opensuse-factory/2014-03/msg00333.html 179 | 180 | Fedora: http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/194771 181 | 182 | 183 | 184 | Solution Rationale: 185 | ------------------ 186 | 187 | Provide a brief description how the documented solution was derived. 188 | 189 | 190 | Distributions Support: 191 | ---------------------- 192 | 193 | A list of distributions that have pledged to adhere to this specification and 194 | integrate the test into their QA suite. 195 | 196 | 197 | Verification Test: 198 | ------------------ 199 | 200 | tests/distro/userNames.py 201 | tests/distro/groupNames.py 202 | -------------------------------------------------------------------------------- /specification.tmpl: -------------------------------------------------------------------------------- 1 | LSB Specification 2 | 3 | State: "Value of 'State'" 4 | ------ 5 | Acceptable values are: 6 | "Problem Statement" -> Problem Statement has been formulated 7 | "Problem Solicitation" -> The problem statement is being solicited to 8 | distributions to reach agreement on the problem 9 | itself, i.e. is this something that needs to be 10 | solved 11 | "Solution Proposal" -> Solution to the problem has been proposed 12 | "Solicitation" -> The proposed solution is being solicited to distributions 13 | in an attempt to find a consensus solution. 14 | "Accepted" -> A consensus solution has been found and the solution 15 | is ready for implementation. 16 | 17 | The state should be indicated in line with the State: header 18 | 19 | 20 | Problem Statement: 21 | ------------------ 22 | 23 | Add the problem statement that affects multiple or all distributions here. 24 | Explain in detail how the observed problem negatively impacts ISVs or 25 | distributions by having divergent behavior between the distributions. 26 | 27 | 28 | (Proposed) Solution: 29 | -------------------- 30 | 31 | Add a detailed description of the proposed solution in this section. Detailed 32 | implementation suggestions are welcome. Be as specific as possible to provide 33 | a good technical basis for discussion on the various distribution mailing 34 | lists. 35 | 36 | 37 | Solution Discussion Links: 38 | -------------------------- 39 | 40 | Provide links to at least 3 distribution mailing lists where this topic has 41 | been discussed. 42 | 43 | 44 | Solution Rationale: 45 | ------------------- 46 | 47 | Provide a brief description how the documented solution was derived. 48 | 49 | 50 | Distributions Support: 51 | ---------------------- 52 | 53 | A list of distributions that have pledged to adhere to this specification and 54 | integrate the test into their QA suite. 55 | 56 | 57 | Verification Test: 58 | ------------------ 59 | 60 | The list of tests that can be incorporated into distribution QA testing 61 | frameworks. 62 | -------------------------------------------------------------------------------- /tests/distro/groupNames.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/python 2 | 3 | import grp 4 | import sys 5 | 6 | # FIXME: does not run on CentOS 6.5 7 | 8 | lsbGroups = { 9 | 'root' : 0, 10 | 'nobody' : 65533, 11 | 'nogroup' : 65534, 12 | } 13 | 14 | for grpent in grp.getgrall(): 15 | if grpent.gr_name in lsbGroups: 16 | if grpent.gr_gid != lsbGroups[grpent.gr_name]: 17 | print 'GID for group %s does not match specification' %grpent.gr_name 18 | print 'found: ', grpent.gr_gid, ',', ' expected: ', lsbGroups[grpent.gr_name] 19 | sys.exit(1) 20 | -------------------------------------------------------------------------------- /tests/distro/userNames.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/python 2 | 3 | import pwd 4 | import sys 5 | 6 | # FIXME: does not run on CentOS 6.5 7 | # TBD: rework this to follow: man 5 passwd layout 8 | # TBD: hijack the GECOS field to add a bitmap: 9 | # MUST be present 0000 0001 10 | # MUST match LSB_pw_name 0000 0010 11 | # MUST match LSB_pw_uid 0000 0100 12 | # MUST match LSB_pw_gid 0000 1000 13 | # Query: do we care about homes? 14 | # 15 | # sources for assignments in RHT space: 16 | # cat `rpm -ql setup | grep uidgid` 17 | # 18 | # conflict: RHT uses group: 65534 for nobody 19 | # possible conflict: some distributions use 'admin' for 'root' 20 | # 21 | lsbUsers = { 22 | 'root' : (0,0), 23 | 'nobody' : (65534,65533), 24 | } 25 | 26 | for pwent in pwd.getpwall(): 27 | if pwent.pw_name in lsbUsers: 28 | if (pwent.pw_uid, pwent.pw_gid) != lsbUsers[pwent.pw_name]: 29 | print 'UID and/or GID for user %s do not match specification' %pwent.pw_name 30 | print 'found: (', pwent.pw_uid, ',', pwent.pw_gid, ') expected: ', lsbUsers[pwent.pw_name] 31 | sys.exit(1) 32 | 33 | # TBD: get rid of un-sourced numeric constants 34 | # TBD: check for the inverse case of a username found 35 | # but not matching 36 | --------------------------------------------------------------------------------