Uid >= 1000

ddan · #1 28th October 2011, 05:20 PM

Greetings,

I was wondering how important is that users and groups be 1000 or greater. When I try to create a new user it warns me if I create the user below 1000. The problem is that I have years worth of backups that would be worthless if I change the UIDs. Also the root of all my backup discs is a user of UID 501. So I would rather not change the UIDs. Is this absolutely necessary?

ddan

jpollard · #2 28th October 2011, 06:29 PM

No.

It is my understanding that this is to become more compatible with other distributions.

The main advantage is that it reserves more UIDs for various system usages (such as database systems, captive/jailed processes and such).

Operationally, there is no difference.

ddan · #3 28th October 2011, 06:42 PM

Thanks jpollard, I was hoping that was the case.

ddan

**AdamW** · #4 28th October 2011, 10:40 PM

That's not entirely accurate.

It's not 'to become more compatible with other distributions', really, though that's a handy side benefit. It's because we're running out of space below UID 500 for system users. If you keep using 501 you might wind up having trouble with this.

Also, if you're going to stick with 500, you need to edit /etc/login.defs and change 'UID_MIN' and 'GID_MIN' to 500. If you don't, you'll get various problems, because various things read that file to find out what's the lowest UID that ought to belong to a 'real user'. For e.g., accounts with UIDs below 1000 don't show up in GDM unless you change that.

jpollard · #5 28th October 2011, 10:57 PM

Odd. Mine still shows up in gdm without problems and I still have 500,500.

The only thing I know of that uses those defaults is the adduser procedures.

They are only defaults after all.

fpmurphy · #6 29th October 2011, 04:19 AM

If you upgrade rather than do a fresh install, the boundary value remains at 500.

jpollard · #7 29th October 2011, 09:51 AM

My F15 was a fresh install into a VM. Maybe this was a F16 change.

***DBelton*** · #8 29th October 2011, 04:21 PM

yes, it is a F16 change. F15 still started the users at 500.

I bit the bullet on my F16 install and did a chown on all the files on my drives to change the user to 1000 instead of 500. Just took a few minutes to change it on 8 2TB drives.

I just did this on each drive:

chown -R --from=500:500 1000:1000 *

jpollard · #9 29th October 2011, 05:36 PM

Now change it on your backups.

I guarantee you it won't be that easy unless your backups are live filesystems.

And it takes a lot longer if you have a lot of files.

**AdamW** · #10 29th October 2011, 07:05 PM

what is this thing you call 'backup'?

jpollard · #11 30th October 2011, 01:02 AM

I don't know about you, but I like to have my files after a disk failure, or a fat fingered failure...

***DBelton*** · #12 30th October 2011, 01:37 AM

Backups are just that.. Backups and NOT meant to be changed. You go messing around trying to change your backups and that's when you lose data.

I have backups of my important data both before and after I changed the user to 1000, so I can restore either one I wish. If I restore the older one with user 500, the data will still be restored. All I have to do is change the user on it again.

Since I don't back up my OS, there really is only 1 user to contend with on my systems here, but I can see where it could be a little more involved if there were many users on a system. In that case, I would keep a script file of the before/after user numbers and run it against files restored if they were from a backup before changing them. Wouldn't be too hard to create a table of before/after user numbers, then feed that into the chown command to do the change. (or even just a big list of chown commands with the user numbers hardcoded in would work)

jpollard · #13 30th October 2011, 12:25 PM

That depends on HOW the UIDs are in use, especially when you have to recheck the security labels involved, and how many users there are.

One problem with your method is that restored files could have any UID, and may not be in the appropriate tree - and during the time the wrong UID is on the files, the wrong user may gain unauthorized access to files.

In some places, this isn't a problem. In others it is a possibly criminal offense.

One place I worked had to do just this. Unfortunately changing UIDs wasn't as simple as "add 500 to UID and GID"... Turned out there were cyclic graphs involved - the target UID was already in use, so it had to be given a totally unused UID (outside the loops), then the first uid could go to the target UID, and the redone UID could be put to its target.

Took three passes over 15 million files... and the backups had to be invalidated, and the system was officially down during the renumbering.

**AdamW** · #14 31st October 2011, 06:39 PM

jpollard: that's just dull. living on the edge is more exciting. =)

jpollard · #15 31st October 2011, 08:14 PM

Depends on the definition of "exciting".

The most exciting time I had was when a VP shipped out a navigation system without allowing me to finish debugging the unit. $50,000 US per day plus docking fees for 7 days...

We really, REALLY didn't want to renumber the system because we knew it was going to take a weekend - and the system vendors didn't want to because if there was a problem the backups would be worthless. Each pass of the renumbering had to be done manually, and the system couldn't crash in the middle of a pass - that would leave things really messed up, and no good way to know where it was in the process.

To minimize the risk we actually did 4 passes - the first pass was those accounts that were simple old uid-> new uid changes where the new uid had never been used. This case just ment that the old uid would be unused in the result. At that point a backup was made (3 hours or so). Then the first pass of handling the cyclic problems - current uid -> temporary uid. As I recall there were 350 - 400 UIDs involved. took about an hour, then a pass taking the current uid to the new uid (another hour) then the last pass taking the temporary uids to the new uid (and another hour). Once that was finished, another backup.

Fortunately for us, the backups didn't have to include user data (they were all on an HSM and had already been forced to migrate to tape). If they had, the backups alone would have taken a week or longer (we never backed up all the users data outside the HSM, 300+ TB of data would take forever.... and the system couldn't be available either).

As it was, we took less than a day, and gave the system back to users early (scheduled two days downtime in case we had to restore, only used about 12 hours).

Fortunately, I didn't have to battle for the downtime (it was out of my pay scale, so my manager did. It was between the customer requirements, customer representatives and my management - and there were two levels present during the negotiation).