Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Input Devices Red Hat Software Linux

Fedora 16 Will Number UIDs From 1000 124

Posted by Unknown Lamer from the two-hundred-uids-should-be-enough-for-anyone dept.
dotancohen writes "Sharing users between Fedora and Debian-based distros just got a little easier. Beginning with Fedora 16, the Red-Hat based distro will number its human user UIDs starting from 1000, as opposed to the old 500. Though this change is intended to facilitate interoperability with other distros, it risks breaking backward compatibility with older Fedora releases including the newly released Fedora 15."
This discussion has been archived. No new comments can be posted.

Fedora 16 Will Number UIDs From 1000 More

Fedora 16 Will Number UIDs From 1000

Comments Filter:

  • Wake me when we fix something really important.

    • Re:Still no cure for time_t... (Score:5, Informative)

      by armanox ( 826486 ) <asherewindknight@yahoo.com> on Wednesday May 25, 2011 @11:12AM (#36239928) Homepage Journal

      time_t is fixed for 64-bit systems. And for the 32-bit systems, well, we still have until 2038 to fix that problem.

      • time_t is fixed for 64-bit systems. And for the 32-bit systems, well, we still have until 2038 to migrate to 64-bit platforms. Or maybe 128-bit platforms.

        FTFY.

      • Re: (Score:2)

        by Z00L00K ( 682162 )

        So either migrate to 64-bit (or a higher bit count) or perform a hack.

        But I suspect that most systems will be 64-bit by then - if we still use computers.

        • But I suspect that most systems will be 64-bit by then - if we still use computers.

          Are most systems even PCs? Some embedded systems still use 8-bit microcontrollers for cost reasons over thirty years after the introduction of the MC68000 CPU, and I imagine that even thirty years into the future, there will still be countless embedded systems that use 32-bit ARM cores for cost reasons.

          • Re: (Score:2)

            by batkiwi ( 137781 )

            If you actually do some thinking you'll realize that's not completely true.

            Most embedded systems are running 8 bit risc chips, but how many of them care about the current exact time, and how many of them run unix (which is the combo necessary for this to be unsurmountable).

            32bit ARM chips are so low power and so cheap nowadays that I can easily imagine the crappiest embedded processor you can get in 10-15 years will be 4 core, have ~8mb of onboard program memory (as opposed to the 128kb I'm used to today),

          • Re: (Score:2)

            by jandrese ( 485 )
            How many of those will care about the date though? My microwave doesn't give a crap what year it is.

            • My microwave doesn't give a crap what year it is.

              Reminds me of a particular scare story run by a Norwegian tabloid (Verdens Gang) some time during the y2k-bug craze with the following reasoning:

              * Computers are vulnerable
              * Even your waffle iron may contain a chip for temperature regulation, this is surely a kind of computer, right?
              * YOUR WAFFLE IRON WILL STOP WORKING AT JANUARY 1ST 2000!!!111

              Funny and sad at the same time. I actually sent an email to the journalist where I politely pointed out how ridiculous this was. His reply was basically that he didn't

        • No, not all of them I think. We'll still have a need for smaller CPUs, and we'll still have a need for file systems with small overhead, and we'll still have archived files using older formats.

        • We'll be using primates! [wikipedia.org]

      • Depends if it's signed or unsigned 32-bit systems.

        • Re: (Score:2)

          by armanox ( 826486 )

          time_t is a signed int

          • True, but there are a LOT of systems out there that use "unsigned long" for "time_t", and some that use "unsigned long" without a typedef attached. They aren't Unix though.

            Time is one of those complex issues that some people think is easy to solve. Ie, a solution that is great for file time stamps may be completely wrong for storing a patient's date of birth. Something that can handle patient ages may be inappropriate for archaeological or scientific use. You get something that's appropriate for archaeo

      • Re: (Score:2)

        by hey ( 83763 )

        Do you really need a entire 64-bit OS to redefine time_t ?
        I think its already defined as a long (on 32 bit systems).

  • who thinks so what?
    I've been a Fedora user since core 5, but I'm on a single use box. Can't you just simply update all the UIDs to add # so they all start at 1000, or is this more complex than I think?

    • If you're talking about an upgrade, then no. Change the UIDs and all of the files that were owned by the previous UIDs are now orphans.

      Nonetheless, this still seems utterly unimportant.

      • Re: (Score:2)

        by unrtst ( 777550 )

        I've been through this. Haven't noticed any other replies in any threads that have had to go through this.

        I've got tons of backups and drives and external drives and network filesystems... all with my users uids in the low 500's. I left them there... and IMO, that *should* just work.

        The biggest annoying problem I ran into - GDM wouldn't display those logins. They had the same group bindings, but it wouldn't show them. I dug around all over, and couldn't figure out where to change this "low uid" setting... a

        • Re:Am I the only one (Score:4, Informative)

          by nabsltd ( 1313397 ) on Wednesday May 25, 2011 @01:30PM (#36241978)

          I'm perfectly fine with them changing the default... but MAKE IT CONFIGURABLE! It'd just have to be one file in /etc, so one could easily jack with it for migrations. How difficult is that?!? Who knows, maybe it already exists and I just couldn't find it?

          You mean like /etc/login.defs?

        • Re: (Score:2)

          by icebike ( 68054 )

          I've been thru this years ago with Suse. For a large shop it can be a bitch, best left to
          when moving to a new server with the luxury of time. It was easily configurable
          in SLES, and still is. In fact I still have some servers running the old uid ranges.
          No actual use of uids above 500 by system accounts yet appears in most distros.

          But for most systems, we just ran a script to chown the file system.

          For a larger shop, I can see where this would be a problem.
          The network file systems seem to be the biggest pro

      • Re:Am I the only one (Score:5, Informative)

        by icebike ( 68054 ) on Wednesday May 25, 2011 @01:43PM (#36242148)

        If you're talking about an upgrade, then no. Change the UIDs and all of the files that were owned by the previous UIDs are now orphans.

        Nonetheless, this still seems utterly unimportant.

        Well, actually, that's not exactly true.

        I've been thru this with other distros in the past, and in-place upgrades are never really a problem as you mention,
        because the same users/groups are retained. Therefore no files become orphans.

        New users just start higher when they are added. You can also make a simple setting to continue using 500 as the first user
        if you want, you are not forced to start at 1000.

        Moving data to a new server is where it gets messy, to say nothing about NFS coordination.

        In our case, being a small size installations we opted to simply build a "find and chown" script to be run once, rather than
        continuing with the legacy numbering.

        • Now I'm not sure about the details of this. Will this actively prevent me from, as root, explicitly creating a user with whatever UID I want?

          I assume (but am not sure) that I can force a uid when necessary, and this is only how users are added when the UID isn't explicitly given. Large shops almost always specify the UID, either through custom tools or by pushing a password file around. This won't affect them much.
          (Assuming I'm correct in my understanding, of course)

          • Re: (Score:2)

            by icebike ( 68054 )

            Your assumption is correct as far as I know.
            Other Distros that have converted to a 1000 base in the past, and it was not a problem to create a user using the old numbers, and usually just a minor setting somewhere to continue using the 500 base if you wanted to.

            (I believe this is stored in /etc/login.defs in opensuse, might be somewhere else in Fedora.).

            That being said, I'm guessing about just how Fedora may implement this. I assume they will follow the industry.

    • You'll need to find / -uid [number] -exec chown [new number]:[new gid] {} \;
      • Forget that. This guy [slashdot.org] has the real answer. My answer was off the cuff, and I didn't think about files with differing gids.

        • Re: (Score:2)

          by icebike ( 68054 )

          Even THAT GUY trivializes the problem when you have a ton of users and or NFS shares that have to be
          coordinated.

          And god help you if things get out of hand and people start adding users to the new system before
          you move all the old users over and you end up with a patchwork of numbers.

          For Joe Random User's laptop, its just not a problem.

    • If you were to change a users UID, you would have to go through all the files in the system an update the UIDs as well. This is simple if all the drives are mounted at the time of the upgrade, and you want them all to be changed. However it becomes more of troublesome you have removable drives. Also, what if one of the mounted drives is a live backup; do you want to change the permissions on that or not. And you have to think about how you are going to handle restoring from a offsite backup with different U

      • Don't forget the possibility that you may already have UID's of 1000 on your systems. So simply doing the find commands that several people have recommended is asking for some asshurt.

        • Please tell me, when was the last time an upgrade changed the your normal user UIDs? Why would an upgrade do that?
           
          Oh, and there are several ways to extract out the UID from the passwd file, reverse the list, then step through the list using each UID to do the "find exec" above.

          • Please tell me, when was the last time an upgrade changed the your normal user UIDs? Why would an upgrade do that?

            He's talking about changing UIDs on existing users to move those below 500 up above 1000. An OS upgrade doesn't force that; changing the default UID numbering system does.

            Oh, and there are several ways to extract out the UID from the passwd file, reverse the list, then step through the list using each UID to do the "find exec" above.

            So you start by changing UID 500 to UID 1000, and then you get to your 500'th existing user who happens to have UID 1000. You happily find all the files belonging to UID 1000 and change them to 1500. Including the files that originally belonged to UID 500 that you changed to 1000 just a few minutes ago...

            It doesn't even take having 500

            • Re: (Score:1)

              by AvitarX ( 172628 )

              I suspect you missed the purpose of reversing the list.

            • He's talking about changing UIDs on existing users to move those below 500 up above 1000. An OS upgrade doesn't force that; changing the default UID numbering system does.

              First off, there will be no existing users if the system is a new install. Second, if the system is already installed, then it is an OS upgrade. Third, even if it is an upgrade with UIDs over 1000, there is no problem because the UID system takes the lowest AVAILABLE UID over the limit.

              On a new system, the UIDs will start at 1000.

      • Why the hell would you change a user's UID?

        • Re: (Score:3)

          by vlm ( 69642 )

          Why the hell would you change a user's UID?

          My suspicion is we're about to have a script unleashed upon us that whines when it sees files owned by UID inside a certain range anywhere but inside /home and /tmp, or a magic partition finder that finds /home by looking for uids in a certain range, or every file inside a certain UID range gets wiped out of /tmp with a different timeout than UIDs outside that range, or only files within a certain UID will be backed up (because its dumb to waste backup time and storage on /bin/ls, especially if it got haxor

          • Re: (Score:2)

            by SETIGuy ( 33768 )
            That would be a good reason not to use those programs, or change distributions if you are forced to use them.

      • why the hell would you change anything? This UID=500 is yet another in the long line of redcrap stupidities (and I'm RHCE4), but you *CAN* create users with UID of 500 if you want to.

        And if you're upgrading, I doubt if they would erase /etc/passwd unless that's SOP for redcrap upgrades. it's been so long since I have to suffer through redcrap.

    • The only problem I see with writing a script that would simply recursively "chown" (change the ownership of) all files in descending uid-order, would be that unmounted filesystems, or remote filesystems, might complicate matters later.

    • Re: (Score:2)

      by ianare ( 1132971 )

      An important element is, as often, totally ignored in the summary :

      We are not in situation that 500 IDs for system accounts ought to be enough for anybody.
      Actually, it was not 500. It was 299 because range 0-200 is for reserved IDs.
      There are 799 non reserved IDs for system accounts available after this
      change.

  • I suppose RHEL will make the switch in RHEL9. At least I know to prepare...

    • Re: (Score:1)

      by Anonymous Coward

      At this rate, Fedoras 14 - 22 will be rolled into RHEL7.
      RHEL6 is based on the word done in Fedoras 7 - 12/13.
      RHEL5 was based on work up to FC6.

  • Why should this break backward compatibility? It surely won't modify existing users' IDs when upgrading, only when creating new users, most commonly (for home users) meaning on new installations only. I can't think of any real reasons this change should break anything.
    • They're probably planning on putting daemon users above 500. I feared such when they started encroaching into the 300s and 400s (forcing me to move my own custom daemon users).

      • Not to mention the security implications of this. Tripwire, and I'm sure a number of other policy auditing systems, expect user accounts to start at 500, and do system wide permissions checking, and user_id -> service based auditing on this. Including running processes etc. This won't be too much of a pain to fix, but it will have to be fixed none the less. Oh well, C'est la vie.

        • It is absolutely trivial to fix. You pick the first free UID over when grabbing a UID for a new service. There is no reason to hardcode a UID, ever.

          • It is absolutely trivial to fix. You pick the first free UID over when grabbing a UID for a new service. There is no reason to hardcode a UID, ever.

            That's fine when you're using an existing system, but if you install a new OS, and suddenly discover that /etc/passwd already has entries in the 500's, you'll have some extra work chown'ing/chgrp'ing a bunch of user files on /home, /usr/people, etc. Not a huge issue, but it's something you have to keep in mind for Fedora16 now.

          • I agree, just takes time that's all. And I guess I've seen 500 as a fundamental constant in the universe, so when it get's changed I'm not really sure yet, what the ramifications could be.

            • How about all the UIDs and GIDs on back up tapes?

              Any one who says this is all just trivial doesn't work with big enough systems. And when the auditors ask for the whole process to be documented?

              This may need to be done. But if it does I am not sure we should stop at 1000. I wouldn't want to go through this again in 5 years.

            • Argh. I just updated a newly installed RHEL 6 box before updating /etc/password, shadow, group... A new daemon just started using GID 500. >:-(

      • Re: (Score:2)

        by SETIGuy ( 33768 )
        I'm sitting at a networked Fedora 14 system. This NFS networking environment has been in continuous use since about 1987. The lowest active user number is in the 400s the highest is in the 9100s. We will not be changing user numbers. We will not use distributions that force us to change user numbers. We will not use utilities that force us to change user numbers. That will be all.
        • Just set the UID explicitly. If you are relying on which order your users are created in you have bigger problems. You aren't forced to anything.

  • They should have started UID's at 9001 to make RedHat MEME compliant.

    • Yet how will this interoperate with the Japanese version of RedHat MEME when that starts at UID 8000?

      • Yet how will this interoperate with the Japanese version of RedHat MEME when that starts at UID 8000?

        Well, actually, this will be fully compatible to the Japanese version; The docs state that compliant implementations start the UIDs at over 8000, which 9001 clearly is.

  • I am not a UID! (Score:1)

    by Anonymous Coward

    I am a free man!

  • Windows systems have all kinds of reserved rights for UIDs below 1000, so this is a good step as far as that's concerned. Is it a concession? I don't think so. It might be kind of a pain, but really how hard is the find command to search for and replace UIDs and GIDs on a system. Don't you do that sort of thing for fun anyway?
    • We use centrify express and the uid/gid conversion results in a number far higher than 1000. Its a good system if you start out that way but will be a pain when you change uid/gid schemes. I dont think its going to be a problem with a really good system administrator group because uid/gid combinations should have been standardized from the start for service accounts and users.

  • Since it only takes about 30 minutes to set up network wide single signon with LDAP and kerberos, even (especially?) at home, I'm not seeing this as having much impact. I use afs so I don't much care about the NFS/UID nightmare either.

    I was recently thinking about this, and the last time I added a user to my LDAP and kerberos at home was when my daughter was born (figured she'd need it a couple years later, and in fact now she does). To add another user at home, not only would I have to look up again how

    • Since it only takes about 30 minutes to set up network wide single signon with LDAP and kerberos, even (especially?) at home, I'm not seeing this as having much impact. I use afs so I don't much care about the NFS/UID nightmare either.

      The problem is, where do you put the database? I don't have any low-power machines reliable enough for the job. I suspect most people have even less :p

    • Re:LDAP and Kerberos (Score:5, Funny)

      by discord5 ( 798235 ) on Wednesday May 25, 2011 @01:35PM (#36242054)

      Since it only takes about 30 minutes to set up network wide single signon with LDAP and kerberos

      Ah yes, I remember this particular book: "Setting up LDAP in 30 minutes". You'd expect it to be a technical manual, but it's actually a novella about a sysadmin who set up LDAP in 15 minutes. Driven by his passion for a single sign on solution and pressed for time he did a quick setup, and things were great. That is until he was supposed to link those userids back to e-mail accounts for the e-mail server, which coincidentally didn't support his particular LDAP layout.

      "It's okay," he spoke, "I've still got 15 minutes to spare. In that time I'm sure I can read the manpages for sendmail, qmail and postfix and still have time to stroke my manly beard.".

      And thus he read the manpages, setup his particular mailserver of choice properly, and stroked his manly beard. Now that every user could connect with SSH to the servers they needed to be on, mail was being delivered, and the manly beard was stroked his manager approached him.

      "Hey, I was trying to access www.testyourmanagementskills.com, but I get this weird error saying Access Denied. I think the Internets are broken, I've never been denied access to the Internets before. Could you come have a look?"
      "Sure thing, I'll be with you in a sec.", the sysadmin answered still enjoying the rough sensation of stroking his manly beard.

      Sure enough, the squid proxy server was not configured yet to authenticate through the LDAP server and was now broken. "I'll be right back," the sysadmin told his manager, "I have to fix the internets". And sure enough, once the sysadmin had dug through the manpages of his clustered setup of squid proxy servers a few hours later everything was up and running smoothly except for those few glitches, but the url for testyourmanagementskills.com passed through the proxy logs so the most important part was taken care of.

      "Time to stroke my manly beard again", the sysadmin thought, but before he had the chance to grab for his manly attribute he was quickly interrupted by the secretary who was trying to update the intranet. "I think the intranets are broken too," she complained in a nagging voice, "I was trying to upload pictures of kittens to improve the mood now that half of the IT stuff isn't working, but if the intranets are down I can't do that. FIX MY KITTENS!". Sure enough, the apache server running the intranet site hadn't loaded mod_ldap, hadn't set up in any other way than ye olde htpasswd password files, and sure enough some of the applications on the intranet site needed to be reprogrammed as well to handle the new and improved magnificent single sign on. Luckily for him the mod_ldap page explained pretty well what needed to be changed, so after a quick lunchbreak the apache server was up and running again (except for a few nasty PHP errors, but the kittens were back on the intranets, so who cares?)

      "You know, " spoke the accountant, "I've got to hand it to you. You managed to fix a lot of stuff today that broke all of a sudden, but I still can't access the accounting excel sheets. I need to update the invoices and I just can't seem to do that.". Sure enough, the samba server hosting the accounting files wasn't configured for LDAP either. The sysadmin quickly went to work, and grabbed the samba documentation, and that is where the real problem began. You see, gentle reader, the documentation for samba isn't just a 3 page document saying "put this here, this here, and that there, and then /etc/init.d/smb restart" but a hefty document gently introducing you into the world of "domain controllers" and "shares" and the various quircks and oddities, such things as WINS servers and all that fun jazz. Oh, the original setup was never anything complicated, but a good LDAP setup for samba (or rather a good samba setup for LDAP) requires a bit of planning and care especially if you have a lot of users.

      After reading through the various manuals and the small hand

      • Re: (Score:3)

        by smash ( 1351 )

        Although long-winded, the post has a point. Anyone who has ever tried to set up any sort of non-basic authentication on a unix box doing anything other than really basic desktop shit will have run into similar problems. Getting the OS to log you in using LDAP is the easy part. Getting all the related services to use LDAP (and doing a full audit before hand without missing anything to ensure that everything can be configured for LDAP) is not.

        Maybe its simpler if you're starting out from scratch and hav

    • Re: (Score:1)

      by zpiro ( 525660 )
      Don't ever switch filesystems, AFS locks you in for life!
      AFS volume based backup *shudder*.

      AFS is great as long as you don't need performance.
      However, there is some interesting developments in AFS+OSD, but this is also mostly for those who painted themselves into a corner.
      Personally I'd much rather "suffer" and use something like GlusterFS (which suffers in small file I/O), but not big files.
      Only AFS and NFS does CacheFS.

  • How is this news at all?

    Fedora and RedHat have had the ability to explicitly set UIDs and GIDs for years.

    I've been explicitly starting UIDs at 1000 doing that since like 1998. Its not a big fucking deal, tripwire or otherwise.

    And any distro that has a problem with non-system UIDs starting at 500 should be aborted as being hopelessly broken.

  • This change doesnt really do anything important. It means that when you add a user without specifiying a uid it will default to the next available uid after 999. The only issue this will pose in a real environment is if there is no centralized account administration and sys admins are not paying attention. I honestly use centrify express, which uses arbitary high uid scheme, based off active directory (unfortunately a required to use it), which is something that can be configured for ldap/kerb setups too.
  • Why is this an issue? Unix admins ought to be able to handle this. Noobs shouldn't even care. Do they even know what a uid is? why?
  • The numbering should start with 1025.

    You tore me away from Oprah's final show for this? Not for long...

  • MY distro goes to ELEVEN hundred. :-)

  • such progress...

    uid's used to be encoded in 8bits, 0-255 and some software would break with 128-255 being wrongly converted into a negative integer...

    now we start at 1000... I guess it took a while to access the impact of PIDs going beyond 30000...

  • Hmm, now I'm left wondering what UID scheme Fuduntu [fuduntu.org] uses.

  • I dual boot systems, and I like my sudo user on Ubuntu to be the same number as my sudo user on Fedora. Before it was a manual procedure to create dummy user at 500, then a sudo user at 1000. Wonderful decision

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Close