Fedora 16 Will Number UIDs From 1000

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."

Comments

This is progress in the Linux world?

[ColdWetDog]

No wonder it's not the year of the Linux desktop yet.

Sheesh. No shiny. Requires mathematics to understand.

Lame.

Re:This is progress in the Linux world?

[Z00L00K]

The UID:s are a minor issue for any well-seasoned *NIX admin.

But an evolution would be to convert to GUID:s, however that would make things really awkward in some cases and really break compatibility.

Re:This is progress in the Linux world?

[Anonymous Coward]

It would be news if other distros adopted (and installed) the LSB as a standard OOTB. You know who you are...

This is not a problem to me as our scripts all thave the ability to work from different group numbers. This was done so that they could work on the different platforms. I can now look forward to deleting a load of code as it will be redundant.

Re:This is progress in the Linux world?

[bsDaemon]

a "well-seasoned *NIX admin" isn't the target market for the "desktop" distributions, anyway.

Re:This is progress in the Linux world?

[jedidiah]

What "problem" are you expecting the "n00b" to have with the status quo exactly?

Never mind where the "user" accounts start. There should be standardized values for application ids and those should be part of the LSB.

Re:This is progress in the Linux world?

[bryan1945]

Just be happy they didn't decide to go on multiples of pi.

Re:This is progress in the Linux world?

[Anonymous Coward]

it maybe a desktop distro but the changes made in the distro end up going into the server distro eventually....

Re:This is progress in the Linux world?

[Anonymous Coward]

What does your remark have to do with the story? "Durh-clicky" users see neither Windows' user GUIDs nor Linux's UIDs. If anything Windows has a more complex numerical user identification system (which, IMHO is bettter). Is this why Windows is not mainstream? Or are you just trolling?

Re:This is progress in the Linux world?

[hobarrera]

Well, suddenly, I don't have permissions issues when sharing my USB drive between my fedora box, and my GF's ubuntu box. Minor as it may be, it saves me a chmod, or chown every time I need to copy large files. Not to mention the hastle it saves newbies.

Re:This is progress in the Linux world?

[Obfuscant]

a "well-seasoned *NIX admin" isn't the target market for the "desktop" distributions, anyway.

When one has to administer them, yes.

This solves nothing for the noob, since the system is assigning UIDs and unless you have just one user on each system, there is no guarantee that the UIDs for the same user will be the same between machines, unless you do them by hand. If you do them by hand, you can make them be whatever you want and this doesn't help.

This is still going to be a problem for me, since my UID for the last 20 years has been below 500 and I've always had to set mine on the desktops and servers I've installed, where the install script thinks it knows better than I do what my UID should be.

Re:This is progress in the Linux world?

[adolf]

Never mind where the "user" accounts start. There should be standardized values for application ids and those should be part of the LSB.

Why should I care what UIDs my applications run as?

Re:This is progress in the Linux world?

[Anonymous Coward]

So in other words, it doesn't solve your existing problem, which is that you've been too lazy to set up an NFS usermap so you can gradually migrate to a higher UID?

Unless you just don't want to, in which case your existing problem is that you like to complain, and only therapy can resolve it.

But in either case it doesn't ADD any headache for you - you already manually assign your UID. This changes nothing.

Re:This is progress in the Linux world?

[jedidiah]

The same daemon might run on more than one machine and may need to be aware of more than just the local machine.

Generally, more determinism in a computer is a good thing.

Re:This is progress in the Linux world?

[adolf]

Doesn't /etc/passwd do an acceptable job of this?

Re:This is progress in the Linux world?

[AvitarX]

this has been bothering me lately.

why does linux make external drives such a pain?

There should at the very least be an option to remount a drive as full control by the active user. With an internal disk it makes some sense, but with a thumb drive the bar is just too low to get it plugged into a computer one has root on, so the permission enforcement becomes a real pain.

maybe m dense though, as don't see the harm n users being able to do arbitrary mounts ether.

Re:This is progress in the Linux world?

[hobarrera]

I really agree. There should be a permission-stripped version of ext4 for external drives.

Still no cure for time_t...

[HaeMaker]

Wake me when we fix something really important.

Re:Still no cure for time_t...

[armanox]

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

Re:Still no cure for time_t...

[Anonymous Coward]

So it will be start being fixed around 2037...

Re:Still no cure for time_t...

[kmdrtako]

2037? Why rush? It won't be a problem until 19 Jan 2038.

I'm sure we can wait at least until the 15th or the 16th to start working on a fix.

Re:Still no cure for time_t...

[idontgno]

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:Still no cure for time_t...

[Kjella]

So it will be start being fixed around 2037...

Anything newer than an Atom N2xx or AMD since I dunno, Athlon 64? will run a 64 bit OS and so probably all future processors too. Even SoC systems probably have more than 4GB of RAM by then...

Re:Still no cure for time_t...

[Z00L00K]

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.

Re:Still no cure for time_t...

[Darinbob]

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

Re:Still no cure for time_t...

[Darinbob]

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.

Re:Still no cure for time_t...

[armanox]

time_t is a signed int

Re:Still no cure for time_t...

[hey]

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).

Re:Still no cure for time_t...

[Darinbob]

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 archaeological use and it will be inappropriate for small file systems or task scheduling.

Re:Still no cure for time_t...

[rwa2]

Sorry, even 256-bit is passé

http://en.wikipedia.org/wiki/Transmeta_Crusoe

Re:Still no cure for time_t...

[Anonymous Coward]

it'll all be in the cloud by then.

Re:Still no cure for time_t...

[CarlosM7]

We'll be using primates!

Am I the only one

[esocid]

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?

Re:Am I the only one

[swordgeek]

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:Am I the only one

[Anonymous Coward]

UIDs are what's stored on filesystems, not user names, therefore you need to update all files of those users if you change their UIDs or they'll be locked out. This might be a bit of an inconvenience for removable media, such as backups.

Re:Am I the only one

[Culture20]

You'll need to find / -uid [number] -exec chown [new number]:[new gid] {} \;

Re:Am I the only one

[Anonymous Coward]

# find / -uid 501 | xargs chown 1001
# find / -gid 501 | xargs chgrp 1001

I mean, really, this is simple stuff. It will take a while on a slow filesystem or a huge filesystem, but it's just two commands. Not exactly end of the world type stuff.

Re:Am I the only one

[Anonymous Coward]

That depends on how the UIDs have been used.

simply adding 500 would work IF and only IF the UIDs are not shared among a network. Sharing is very common.
Normalizing UIDs in an organization can take weeks or even months (remember the backups - each of them must
have something for conversion too).

The next problem is trying to actually do cross compatibility - what do you do when your user UID is in use by a different user on the other system? And then, there are those users that have multiple accounts, one in each of separate organizations that are being merged...

Normally this is addressed via uid/gid maps with NFS.

This is also why arbitrary use of UIDs will always be a problem.

Re:Am I the only one

[Jeremiah Cornelius]

Heh.

Don't tell the guys who think Linux is Gnome about the magic keys.

They might take her out for a drive.

Re:Am I the only one

[Culture20]

Forget that. This guy has the real answer. My answer was off the cuff, and I didn't think about files with differing gids.

Re:Am I the only one

[ianare]

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.

Re:Am I the only one

[rthille]

This should use -print0 and -0 on the find and xargs, otherwise it fails on silly paths with spaces or other weird crap in them.
Also, this only solves the issue of who owns the files, not issues related to stupid software with UIDs hard-coded in them...
Really, it's a big problem, but not because the issue is complex, but because people (developers) do stupid stuff and tracking down all the implications and sources of the problems can be difficult.

Re:Am I the only one

[unrtst]

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... and I haven't seen that posted here either!

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?

As others have mentioned, it's not just file ownership (though that's a significant undertaking when you consider NFS, removable drives, and backups - especially backups). Anything that's honoring this low-uid stuff, and anything that has uid's stored in configs, will need tweaking. Just make it easy to change the default, and this would blow over.

Re:Am I the only one

[jdoff]

Better:

find / -uid 501 -exec chown 1001 {} \;
find / -gid 501 -exec chgrp 1001 {} \;

Or even better would be a short Perl script with a hash mapping old UIDs to new UIDs, and then you only touch each file once, regardless of the number of user accounts on the system.

Re:Am I the only one

[nabsltd]

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:Am I the only one

[Anonymous Coward]

I also asked me where the bus is with those guys who are interested in that change. They might be hiding behind that well known sack of rice.

However, it is always a good thing when distributors start to use the same standards.

Re:Am I the only one

[icebike]

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.

Re:Am I the only one

[icebike]

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 problem here, because the coordination
is a bitch. Then there all all the little uid/gid assignments that might be hard coded if your fstab
that lurk to haunt you.

Re:Am I the only one

[icebike]

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.

Re:Am I the only one

[swordgeek]

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:Am I the only one

[icebike]

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.

Re:Am I the only one

[Anonymous Coward]

Better?? That's actually the worse you can possibly do. It will execute "chmod" once for each entry reported by find. It will take *AGES* to complete. The alternative using xargs will accumulate arguments for chmod and reduce invocations dramatically.

Now, if in your commands above you replace \; by "+", that's a whole different story. In that case "find" alone behaves as "find | xargs" and whether or not that's "better" becomes an issue of personal preference.

Re:Am I the only one

[Anonymous Coward]

You might want to look into the -h option for chown and chgrp.

Re:Am I the only one

[simcop2387]

However with xargs you can run into an issue with there being a limit on the number of arguments to a command. years gone by i think it was 32768 on linux it may be different or configurable now. I think xargs though has a way to tell it to limit the number of them and to run several in parallel also. I would also prefer the perl script method myself since you can handle all translations at once and not have to scan every file multiple times.

Re:Am I the only one

[Skapare]

Yes, the -h option on chown and chgrp is needed to do this right. Also, you'll need to use -print0 on find, and -0 or --null on xargs, to avoid being corrupted by odd file names, including file names with newline characters in them (technically valid).

Re:Am I the only one

[kasperd]

However with xargs you can run into an issue with there being a limit on the number of arguments to a command.

That is not an issue. xargs will run the command multiple times if necessary.

Re:Am I the only one

[SETIGuy]

Or even better.....

# sed 's/:1001:/:501:/' /etc/passwd >/etc/passwd.new
# cp /etc/passwd /etc/passwd.bak
# cp /etc/passwd.new /etc/passwd

One of benefits of linux is that you don't have live with the arbitrary stylistic decisions of the distro maintainers.

A good step

[Anonymous Coward]

Now if they could just agree on .deb or .rpm. They're both just .tar files with slightly different structures anyhow...

Re:A good step

[icebraining]

Actually a .deb is an 'ar' archive which contains a text file and two compressed 'tar' files.

Re:A good step

[Mr. Jaggers]

Actually an .rpm is a binary with metadata headers and a 'cpio' archive which contains the files.

And RHEL

[Culture20]

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

Re:And RHEL

[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.

Compatibility

[Per Wigren]

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.

Re:Compatibility

[Culture20]

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).

Re:Compatibility

[bobaferret]

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.

Re:Compatibility

[Brian Feldman]

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.

Re:Compatibility

[Culture20]

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.

Re:Compatibility

[Anonymous Coward]

So, if I understand correctly, Tripwire (and possibly other policy auditing systems) have no facility for dealing with more than 500 UID's? Sounds pretty sad to me.

Re:Compatibility

[bobaferret]

NO, there's absolutely a way to deal with this, things are just going to have be changed is all. And that takes time and attention to detail. It's all part of the job, but it's one more thing none the less. SELinux is finally settled down, and now we've got systemd, and base UID changes, as we'll as virtualization and significantly heavier use of kernel cgroups. I'm just saying it's one more thing on the list to deal with in an already complicated and busy few years. The amount of effort required to go from RHEL4 to RHEL6 and still maintain PCI-DSS compliance and configuration standards is pretty rough at the moment. As Linux and the big distributions continue move away from traditional UNIX ways of doing things there are lot more potential ways to make mistakes, and far less people who understand the security implications, and where the pitfalls are.

Re:Compatibility

[bobaferret]

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.

Re:Compatibility

[jvillain]

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.

Re:Compatibility

[SETIGuy]

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.

Re:Compatibility

[Per Wigren]

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.

Re:Compatibility

[Culture20]

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

Is the news really that slow today?

[Anonymous Coward]

Geez, how does a totally trivial linux factoid makes it to the front page of /.? Not even OSNews finds it worthwhile to do a post on this.

Missed opportunity

[CharlyFoxtrot]

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

Re:Missed opportunity

[Rakshasa Taisab]

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

Re:Missed opportunity

[VortexCortex]

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.

More trouble than that.

[pavon]

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 UIDs. And if you have a networked file system, where all the computers on site share the same UIDs, it could become a real mess. Then there is the issue of config files that contain UIDs (like sudo users). It may be better to leave existing UIDs as they are, and just have new ones start at 1000.

Re:More trouble than that.

[Score Whore]

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.

Re:More trouble than that.

[Anonymous Coward]

chown user:user /home/user -r

(Or was it -R? I forget. Use man.)

Regular, ordinary users shouldn't really have anything they own outside of their home and /tmp. That is root's domain, and that of various service users. Letting non-superusers screw around all over the place is bad practice.
 
I've used ubuntu accessing my home on a centos server via NFS, so I've been through this before.

Re:More trouble than that.

[Brian Feldman]

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

Re:More trouble than that.

[vlm]

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 haxored)

Re:More trouble than that.

[DaveV1.0]

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.

Re:More trouble than that.

[the_B0fh]

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.

Re:More trouble than that.

[Obfuscant]

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 users. If you've delegated user creation to different departments, say, and allocated them ranges of UID they are responsible for, then you might have one user at 500, one at 1000, one at 1500, etc...

The simple solution is, of course, to sort the changes you need to make and do the highest ones first. That way the UID 500 changes don't create files UID 1000 until after you've changed the 1000 to 1500.

This still leaves the issues brought up above. For the one about backups -- if you are doing something this drastic to the file system, you should back up before you do it, do it, and then do another backup.

Re:More trouble than that.

[SETIGuy]

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

Re:More trouble than that.

[Anonymous Coward]

Not a top-notch work of "hiding", since obscurity is bad security, but it's annoying that you can't renumber an old account to a "hidden" if you UNEXPECTEDLY must lend the laptop to mom-and-dad for a week or two with just a few minutes' notice... Next to your full name's login, they see your password-locked pr0n account "plain as day" on Gnome's username chooser and their questions start flowing in:

"Why is this one password-protected when your auto-boot one isn't? Got something to hide from your parents, young man? Does all the secretiveness mean you're hiding a girlfriend from us? Pornography?" They might skip the questions but go and ASK another geek with a grudge for a liveCD and start digging deeper before you even notice your encryption-less attack vector's failure.

Windows' login screen has the same problem, and account renames don't always rename the actual hardcoded username even if you can see a new login name. No real solution for that one either.

Re:More trouble than that.

[AvitarX]

I suspect you missed the purpose of reversing the list.

Re:More trouble than that.

[AvitarX]

use kdm and have that user not pictured.

Re:More trouble than that.

[DaveV1.0]

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. On an upgraded system with the highest UID less than 1000, the next new user would be 1000. And, on a system with a UID over 1000, the next user would have a number equal to the highest current UID + 1. Really, I don't see any issue at all.

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...

I am guessing you didn't really read my comment:

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"

ordering uids == fail

[Anonymous Coward]

how does this help interoperability? are there a bunch of lame
scripts that do different things based on the value of uid? that
would be pretty insane, and not supported. uids have always
been a set with 1 operator: equality. you can test if uid==0,
but if you're trying to order them and do something like
if(uid>=magic) you need a trip to unix re-education camp.

Re:ordering uids == fail

[Kjella]

if you're trying to order them and do something like if(uid>=magic) you need a trip to unix re-education camp.

Yep. It's trying to implement number magic instead of having user groups like local_users, remote_users, daemons etc. to determine what to show where. Welcome to poor design 101, I remember trying to add a ftp server to my box, reusing user and file system permissions is fine but every user I added also appeared on my login screen. They should be in an ftp_users group, nowhere else. But instead we'll use a UID that we can't easily change and can't belong to multiple groups, sigh...

Re:ordering uids == fail

[greg1104]

uids on Debian derived systems start with 1000. If you build a system based on either RedHat or Debian standards right now, the uid numbers are going to be in a completely different range. This makes it even more annoying than usual to do things like create shared volumes where the file permissions are right, when mounted by two different servers running different distributions.

It's also a hassle on dual-boot systems, or ones where you converted from one distribution to the other, too. For example, last week I changed a RHEL server to run Debian. I had to go through 2TB of files and switch all of the UIDs over to the Debian standard for them, mapping user 500 -> 1000. Even though I could have just made the main account use the default RedHat range UID, that 500 number is technically reserved in Debian.

Small things, but definitely moving in the right direction as far as making Linux distributions less different from one another.

I am not a UID!

[Anonymous Coward]

I am a free man!

Re:I am not a UID!

[Trashman]

You are unique and special, just like everyone else...

Good for Samba/Windows interoperability

[mzilla]

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?

Re:Good for Samba/Windows interoperability

[tarius8105]

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.

A script could do for mounted filesystems, but

[jabberw0k]

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.

grammar police

[Anonymous Coward]

its.

i can't believe how much this blog got purchased for.. and they still can't spell.

Re:grammar police

[Anonymous Coward]

user UIDs

They don't seem to think about acronym expansion, either.

Extremely minor implementation detail

[Anonymous Coward]

Why is this a story? Who cares what number you start numbering your UIDs from? It shouldn't actually matter to ANYONE what those numbers are, so this only matters at the point where you create a new user.

LDAP and Kerberos

[vlm]

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 the heck to do it, but I'd need to review all those "Now that you're expecting..." pregnancy books again.

This would have been a Big Deal in the mid 90s when I only had one box, but its not the mid 90s anymore...

Re:LDAP and Kerberos

[drinkypoo]

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

[discord5]

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:LDAP and Kerberos

[smash]

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 have no network to manage a transition for, but if you have existing services to migrate - good luck!

Re:LDAP and Kerberos

[zpiro]

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.

!news

[Fujisawa Sensei]

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.

minor change really

[tarius8105]

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.

sum

[Anonymous Coward]

echo -n "useraccount" | sum = uid

And yet

[Anonymous Coward]

These same people who can parse 12 mile long regexes in their heads can't seem to grasp that it's means IT IS. Seriously, the apostrophe is like the smallest of the keyboard symbols. Is it that hard to understand?

8 bits are still around.

[tepples]

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:8 bits are still around.

[batkiwi]

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), and be capable of handling 64 bit longs even if it's not 64bit native.

And draw next to no power.

Re:8 bits are still around.

[jandrese]

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

Re:8 bits are still around.

[Man Eating Duck]

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 know the details, but had been assured of this by "a computer expert". I still wonder how that story came to be.

Man login.defs

[Anonymous Coward]

See SYS_UID_MAX, SYS_UID_MIN, UID_MAX, and UID_MIN.

You want it the old way, set them the old way. You want them the new way on older Fedora/RHEL, you can do that, too!

Noobs and year of linux desktop

[morgauxo]

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?

I think you meant to say that

[Anonymous Coward]

Fedora now also enjoys Solaris compatibility, like Debian-based Linuxes have for quite some time...

This is an almost-good idea, but could be better

[Lime Green Bowler]

The numbering should start with 1025.

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

double

[virtuosonic]

fedora sucks now it well suck double

Oh yeah?

[sootman]

MY distro goes to ELEVEN hundred. :-)

UIDs *used to be* 0-255, or even 0-127, PIDs 30K

[neurocutie]

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...

Compromise

[rwa2]

Hmm, now I'm left wondering what UID scheme Fuduntu uses.

Wonderful decision

[lsatenstein]

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

most of you don't understand the issue

[Anonymous Coward]

The issue will be related to users whose uid is between 500 and 999, whether you use a remote directory (LDAP, NIS or WINDBIND) or not.
By default, these users won't be able to login (read less_than_1000, for the future settings)
http://directory.fedoraproject.org/wiki/Howto:PAM#Red_Hat_clients_with_UID.27s_less_than_500

It's not a huge issue, but it's really less annoying to change these settings (so to revert them back) instead of changing the UID.
By experience, they also won't appear by default when you'll use system-config-users.

I know quite well this problem since I had lot of users with UID 500 before I migrate everything to RedHat/Fedora.