Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fedora 16 Will Number UIDs From 1000

Unknown Lamer posted more than 3 years ago | from the two-hundred-uids-should-be-enough-for-anyone dept.

Input Devices 124

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

Sorry! There are no comments related to the filter you selected.

This is progress in the Linux world? (0, Troll)

ColdWetDog (752185) | more than 3 years ago | (#36239608)

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? (1)

Z00L00K (682162) | more than 3 years ago | (#36239672)

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? (1)

bsDaemon (87307) | more than 3 years ago | (#36239732)

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

Re:This is progress in the Linux world? (1)

jedidiah (1196) | more than 3 years ago | (#36239898)

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? (1)

adolf (21054) | more than 3 years ago | (#36242654)

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? (0)

Anonymous Coward | more than 3 years ago | (#36240864)

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? (1)

Obfuscant (592200) | more than 3 years ago | (#36242236)

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? (0)

Anonymous Coward | more than 3 years ago | (#36244992)

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? (0)

Anonymous Coward | more than 3 years ago | (#36239706)

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? (4, Funny)

bryan1945 (301828) | more than 3 years ago | (#36240112)

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

Re:This is progress in the Linux world? (0)

Anonymous Coward | more than 3 years ago | (#36241494)

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? (1)

hobarrera (2008506) | more than 3 years ago | (#36241948)

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.

Still no cure for time_t... (0)

HaeMaker (221642) | more than 3 years ago | (#36239662)

Wake me when we fix something really important.

Re:Still no cure for time_t... (4, Informative)

armanox (826486) | more than 3 years ago | (#36239928)

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

Anonymous Coward | more than 3 years ago | (#36239968)

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

Re:Still no cure for time_t... (1)

kmdrtako (1971832) | more than 3 years ago | (#36240360)

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

Kjella (173770) | more than 3 years ago | (#36240486)

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

idontgno (624372) | more than 3 years ago | (#36240462)

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

Z00L00K (682162) | more than 3 years ago | (#36240826)

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.

8 bits are still around. (1)

tepples (727027) | more than 3 years ago | (#36243020)

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

batkiwi (137781) | more than 3 years ago | (#36244524)

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

jandrese (485) | more than 3 years ago | (#36244576)

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

Re:Still no cure for time_t... (1)

Darinbob (1142669) | more than 3 years ago | (#36243078)

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

Darinbob (1142669) | more than 3 years ago | (#36243054)

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

Re:Still no cure for time_t... (1)

armanox (826486) | more than 3 years ago | (#36243688)

time_t is a signed int

Re:Still no cure for time_t... (1)

Darinbob (1142669) | more than 3 years ago | (#36244270)

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

hey (83763) | more than 3 years ago | (#36243724)

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

Am I the only one (1)

esocid (946821) | more than 3 years ago | (#36239664)

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 (1)

swordgeek (112599) | more than 3 years ago | (#36239710)

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 (0)

Anonymous Coward | more than 3 years ago | (#36239764)

# 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 (1)

Jeremiah Cornelius (137) | more than 3 years ago | (#36239824)

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 (1)

rthille (8526) | more than 3 years ago | (#36240992)

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 (1)

jdoff (95905) | more than 3 years ago | (#36241576)

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 (1)

Anonymous Coward | more than 3 years ago | (#36243246)

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 (1)

simcop2387 (703011) | more than 3 years ago | (#36244296)

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 (1)

kasperd (592156) | more than 3 years ago | (#36245070)

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 (0)

Anonymous Coward | more than 3 years ago | (#36243732)

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

Re:Am I the only one (1)

Skapare (16644) | more than 3 years ago | (#36244768)

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 (2)

unrtst (777550) | more than 3 years ago | (#36241446)

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 (3, Informative)

nabsltd (1313397) | more than 3 years ago | (#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:Am I the only one (1)

icebike (68054) | more than 3 years ago | (#36242302)

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 (4, Informative)

icebike (68054) | more than 3 years ago | (#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.

Re:Am I the only one (1)

swordgeek (112599) | more than 3 years ago | (#36242438)

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 (1)

icebike (68054) | more than 3 years ago | (#36242560)

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 (0)

Anonymous Coward | more than 3 years ago | (#36239730)

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 (1)

Culture20 (968837) | more than 3 years ago | (#36239738)

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

Re:Am I the only one (1)

Culture20 (968837) | more than 3 years ago | (#36240670)

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

icebike (68054) | more than 3 years ago | (#36242378)

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.

More trouble than that. (1)

pavon (30274) | more than 3 years ago | (#36239794)

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

Score Whore (32328) | more than 3 years ago | (#36239836)

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

DaveV1.0 (203135) | more than 3 years ago | (#36240984)

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

Obfuscant (592200) | more than 3 years ago | (#36243580)

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

Anonymous Coward | more than 3 years ago | (#36239912)

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

Brian Feldman (350) | more than 3 years ago | (#36240328)

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

Re:More trouble than that. (2)

vlm (69642) | more than 3 years ago | (#36240564)

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

the_B0fh (208483) | more than 3 years ago | (#36242060)

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

Anonymous Coward | more than 3 years ago | (#36239816)

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.

A script could do for mounted filesystems, but (1)

jabberw0k (62554) | more than 3 years ago | (#36239996)

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

ianare (1132971) | more than 3 years ago | (#36240928)

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 (0)

Anonymous Coward | more than 3 years ago | (#36242132)

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.

A good step (0)

Anonymous Coward | more than 3 years ago | (#36239680)

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 (1)

icebraining (1313345) | more than 3 years ago | (#36241058)

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

Re:A good step (1)

Mr. Jaggers (167308) | more than 3 years ago | (#36242628)

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

And RHEL (1)

Culture20 (968837) | more than 3 years ago | (#36239686)

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

Re:And RHEL (1)

Anonymous Coward | more than 3 years ago | (#36241950)

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 (1)

Per Wigren (5315) | more than 3 years ago | (#36239752)

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 (1)

Culture20 (968837) | more than 3 years ago | (#36239814)

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 (1)

bobaferret (513897) | more than 3 years ago | (#36240220)

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 (1)

Brian Feldman (350) | more than 3 years ago | (#36240348)

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 (1)

Culture20 (968837) | more than 3 years ago | (#36240490)

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 (1)

bobaferret (513897) | more than 3 years ago | (#36242258)

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 (1)

jvillain (546827) | more than 3 years ago | (#36242864)

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 (0)

Anonymous Coward | more than 3 years ago | (#36240644)

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 (1)

bobaferret (513897) | more than 3 years ago | (#36242214)

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.

Is the news really that slow today? (0)

Anonymous Coward | more than 3 years ago | (#36239780)

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 (1)

CharlyFoxtrot (1607527) | more than 3 years ago | (#36239792)

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

Re:Missed opportunity (1)

Rakshasa Taisab (244699) | more than 3 years ago | (#36239946)

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

Re:Missed opportunity (1)

VortexCortex (1117377) | more than 3 years ago | (#36240342)

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.

ordering uids == fail (0)

Anonymous Coward | more than 3 years ago | (#36239832)

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 (1)

Kjella (173770) | more than 3 years ago | (#36240812)

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

I am not a UID! (1)

Anonymous Coward | more than 3 years ago | (#36239856)

I am a free man!

Re:I am not a UID! (1)

Trashman (3003) | more than 3 years ago | (#36241758)

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

Good for Samba/Windows interoperability (1)

mzilla (1212676) | more than 3 years ago | (#36239940)

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 (1)

tarius8105 (683929) | more than 3 years ago | (#36241098)

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.

grammar police (0)

Anonymous Coward | more than 3 years ago | (#36240290)

its.

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

Re:grammar police (0)

Anonymous Coward | more than 3 years ago | (#36240870)

user UIDs

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

Extremely minor implementation detail (0)

Anonymous Coward | more than 3 years ago | (#36240344)

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 (1)

vlm (69642) | more than 3 years ago | (#36240476)

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 (1)

drinkypoo (153816) | more than 3 years ago | (#36240810)

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 (5, Funny)

discord5 (798235) | more than 3 years ago | (#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 on the clock moving several hours into the less productive end of the workday, the sysadmin was frustrated. Everyone had left the building, and he heard them complaining to eachother behind his back. His 30 minute single sign on hack had become a gigantic disaster, and the word around the water cooler was that the manager was not all that pleased and there were some nasty rumors of shaving his manly beard as punishment.

"It's okay," he thought, "I can still hack it all together in a single night. I'll show you all not to mock my trusty beard". Oh, and how he showed them all. The next morning the OpenLDAP server had a disk failure and there was no slapd to be seen. Oh Murphy, you sneaky little bastard. The company's activities had now been reduced to gossiping around the watercooler, picking up the phone, gossiping around the coffee machine, and the manager playing Simcity 2000 (because it's a management tool, not a game you insolent fool, now leave before I have you fired).

So... The moral of the story is: HAIRY SYSADMINS SHOULD NOT SETUP LDAP IN 30 MINUTES UNLESS THEY WANT TO LOSE THEIR BEARDS!

Most people have longer conversations about considering LDAP than 30 minutes, and then we're just talking about "Hey, I was considering to use LDAP for storing all my users for single sign on, what are your thoughts on that?" followed by an answer often comparable by the stark raving mad rambling of a lunatic frothing at the mouth with foam resembling the top part of a good capucino (not much unlike this particular little rant, but with more expletives). Having said that, once LDAP is up and running it's quite nice although sometimes a bit tedious to manage. But 30 minutes is a flat out lie, or your network is of such a small nature that LDAP is overkill.

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

It's not a big deal, but you don't just switch from on to the other in 30 minutes. I am somewhat expecting that you have mistaken this amount of time for the amount of time it took for you and your wife to conceive your daughter (perhaps including the dinner before, but preferably something you can put in the microwave). I certainly hope you don't make these kinds of estimations for your wife? "Pregnancy? Meh, just plop her out after 8 or 9 weeks. The delivery itself should be over and done with in 5 minutes. Get it over with already, she only took a few minutes to make you know."

Sorry if this might seem as a personal attack on you, it's not. I just spent the last 3 hours of the day in a meeting about... (drumroll) LDAP. I believe all the parties involved were foaming like a good cappucino at the end of the meeting. If that's a good sign or bad is yet to be determined.

!news (1)

Fujisawa Sensei (207127) | more than 3 years ago | (#36240930)

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 (1)

tarius8105 (683929) | more than 3 years ago | (#36241026)

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 (0)

Anonymous Coward | more than 3 years ago | (#36241338)

echo -n "useraccount" | sum = uid

And yet (0)

Anonymous Coward | more than 3 years ago | (#36241962)

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?

Man login.defs (0)

Anonymous Coward | more than 3 years ago | (#36244160)

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 (1)

morgauxo (974071) | more than 3 years ago | (#36244192)

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 (0)

Anonymous Coward | more than 3 years ago | (#36244696)

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 (1)

Lime Green Bowler (937876) | more than 3 years ago | (#36244920)

The numbering should start with 1025.

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

double (1)

virtuosonic (1880050) | more than 3 years ago | (#36244934)

fedora sucks now it well suck double

Oh yeah? (1)

sootman (158191) | more than 3 years ago | (#36245076)

MY distro goes to ELEVEN hundred. :-)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?