Replies

Actually, password checking may not need elevated privileges. Didn’t on older systems, back before “shadow” passwords… and in low-security environments you might still find such configurations. Inadvisable unless you really can’t help it, but…

And… you know how sudo typically allows you to run a *second* command at elevated privileges without entering the password a second time if you’re quick enough? Yeah, that. It doesn’t stay in memory or anything, it just saves a marker in a file and checks that for time and session differences – and if those are good enough it elevates your privileges without asking for your password.

Yes, this means that if you know where that file goes and have the privileges to write there, you can bypass the password prompt. (Then again in that case you already seem to have pretty much all the privileges, so…)

1 user thanked author for this post.

rc primak

It works because sudo itself needs to run at elevated privileges to be able to grant privileges.

1 user thanked author for this post.

rc primak

By the principle of defense in depth, you do want this fix.

Because if someone manages to be able to run shell commands as you some other way, say from a browser or email fault, they can get root credentials with this.

And also, if you manage to end up with… say, file names… ending in the \ character (it’s allowed in file names just fine in Unix/Linux), running without the fix is somewhat unsafe even in full isolation.

5 users thanked author for this post.

rc primak, Cybertooth, Charlie, OscarCP, DrBonzo

Oh and this is really not limited to Linux.

While I haven’t seen any attempts at reproducing this on other operating systems, it’s not unlikely that sudo is affected across all of them.

Sudo runs on all the BSDs I believe, and MacOS, AIX, HP-UX (both hppa and Itanium), Solaris (i386, x86-64 and Sparc), … and a bunch of other things. Wouldn’t be surprised to find it on Juniper routers for example (JunOS looks very BSD-like), or any number of embedded or integrated systems – VxWorks is POSIX enough that having a sudo on the NASA Mars rovers is not at all impossible.

1 user thanked author for this post.

rc primak

anonymous wrote:

and does windows have “kernel updates?”

Yes, but they’re usually not specifically named as such.

2 users thanked author for this post.

rc primak, Ascaris

The issue is only relevant to cases where there’s another user who is not supposed to be able to gain admin credentials.

Unfortunately any number of things callable from the network can qualify for that if they can be made to call sudo with arbitrary command line arguments.

And after the fix, sudo will work more correctly, though this only affects cases where you had things like file, directory or device names ending in a \ character that you’d use in sudo commands. (Remember, it’s not a path separator in Unix/Linux…)

5 users thanked author for this post.

rc primak, Cybertooth, Ascaris, Charlie, DrBonzo

anonymous wrote:

Things catch fire at 100 ℃

Very few normal things and they tend to be nasty otherwise too. Don’t build your computer out of solid phosphorus…

anonymous wrote:

Pretty sure that a chip would fry and melt the solder as the plastic melts @ 105 ℃

I thought milspec electronics have to survive running at 125 ℃ and PCs built to that standard may still use processors that come from normal production lines… Anyone know better?

Many plastics can take a lot more than that, anyway. PET (the stuff usual drinks bottles are made from) melts somewhere above 200 ℃, around the same as normal lead-free solders.

Leaded solder is usually somewhere around 190 ℃, more expensive types a bit under.

OscarCP wrote:

I have found that certain things are easier to do from the command line, while others are easier to do from the GUI.

Exactly. Use the right tool for the job, etc…

That’ll be the difference between a hard requirement (can be done at all) and a quantitative requirement (making things easier, quicker, feasible with less task-specific training) …

GUIs used to be too resource-intensive to be worth it for just about anything. They’re a lot more affordable nowadays, and the critical threshold… depends heavily on what exactly you’re doing.

It’s now a matter of public record that GUI-like elements were considered for certain military applications quite a bit earlier than the Xerox Alto was made.

I’d note that there are a number of centralized management systems for servers that don’t require a GUI on the managed server to present one to the working administrator for most tasks. This might be a separate product entirely, though. (And there are a number of vendors for these, commercially. Have worked with several such products myself – one of those I’ve used was even sold by the same folks who’d packaged the server operating system on most of the servers we had at the time.)

Also there are a number of choices you can make at build time even for same-architecture hardware.

It’s common nowadays to include information on what those choices were, in /boot/config-{version} … there’s thousands of choices there.

$ grep CONFIG /boot/config-$(uname -r) |wc -l

8781

… yes, 8781 things you can tweak.

Some of those depend on others of course, for example if you choose to not build the “I915” driver (for the Intel GPUs) at all, the other 20 config settings related to that driver do nothing.

So if you’re building for some specific thing, you might know what’ll be in the box and can skip the drivers for all the things that aren’t there. And their initialization at runtime.

Also some things like scheduling will affect how the kernel handles different workloads. If you’re working with realtime audio and/or video, you might want the lowlatency scheduling options. (Available prebuilt on some distributions.) Generic probably has more raw throughput though.

And the various virtualization-focused kernel flavors tuned for running under those kinds of platforms… if you’re paying for CPU cycles on a cloud-virtual server you might not want to spend those cycles probing for sound cards and Bluetooth.

OscarCP wrote:

I had always thought the kernel was one and the same for all distros, because Linus Torvalds “leads its kernel development team.” I’ve heard that said before and understood it to mean that there is one such team that develops the one evolving kernel.

Well from one point of view…

The mainline kernel source code tree is the same one for all the distros, yes.

But you can’t run source code directly so they all take some version of the source and the toolchain, and distribute prebuilt binary kernels. (With some configuration choices locked in at build time, like what CPU models to support and what to optimize for.)

Some have even added extra “out of tree” patches.

And then they usually do the “security only” update thing on top of that, so keep the same kernel major version and backport newer security fixes into it, trying to avoid the “update broke something” kind of issue.
(This is especially needed with closed-source device drivers – nVidia doesn’t seem to keep up with Linus, for example.)

This is why I’m on 5.4.something (Ubuntu 18.04 hwe-edge with nvidia-driver package) for example, while Linus is working on 5.11 … and 5.10.10 is the latest mainline “released” kernel.

I can and have run 5.10 mainline kernels on this thing, but that breaks my graphics features somewhat (nvidia-driver doesn’t work on 5.10 on this hardware, have to use nouveau instead) and other things work differently.

1 user thanked author for this post.

OscarCP

Besides, printers are fairly manageable… because the Windows drivers can be an even worse problem at least for some models, after a few years.

Avoid this by only buying printers that can take a known control language, either as primary or an alternative method. PCL, PostScript, or one of the other languages.

(Yes, I’ve had to use “generic” printer drivers more on Windows than on Linux. Only way to get the old Crystal Reports label printing to work after a Windows Server version upgrade, etc…)

OpenCL is often a bother on nVidia and on low-end models often just not worth it… much easier to get benefits from it with AMD, even just APU integrated graphics cores. Also worked like that in Windows as well as Linux last time I tried any OpenCL benchmarks on what we had at the time.

WSDKS01 wrote:

Outlook in Office 365 has a nasty habit of sending attachments as winmail.dat file instead of the proper format

Actually, that winmail.dat / TNEF issue predates Office 365 and can still also happen with the permanent-licensed versions. (Also possibly some versions of Exchange Server might generate those even when not using Outlook?)

I don’t think there ever was a version of Outlook without that “feature”? I mean, since it’s theoretically a compatibility feature with Microsoft Mail 3.5 and earlier…

anonymous wrote:

It just can’t seem to decide whether it resides on /dev/nvme0n1 or on /dev/nvme1n1 for one time to the next

Well yeah, that’s a bit of a continuous problem with Linux these days if you don’t know to expect it.

Not only can you end up with your internal SATA drives in a different order after a kernel update and reboot, in some cases you can even find them reordered while running… had that happen to me the other week when I was trying to recover data from a broken microsdcard a few different ways.

Oh well, always use /dev/disk/by-id/ or /dev/disk/by-path/ if there’s any chance…

What privilege level were you running the copy with?

Because it’s unlikely to work as a non-administrator unless the computers had shared account management (as in members of the same domain), but I’d expect at least an error about the permissions. And even administrators probably need to adjust file ownership or access privileges.

1 user thanked author for this post.

likescats