Live data from Hacker News

Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

github.com

131–140 of 180 posts

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#131
post #128

Earlier quoted context omitted.

That appears to validate my belief that only Google can competitively take the Linux kernel and build atop it a software stack known as a desktop/mobile/user operating system. And if my assertion that intention prediction and voice search will be competitive features for users, features that rely on mass data collection and expensive top talent, then I think organizations like Canonical or RedHat will fall behind in…

I tend to mix up Linux and Unix and that might be the issue here... But isn't the `Apple Garden` (OSX and iOS) an example of a desktop/mobile/user operating system built on Linux? Apple's no M$, but they are certainly competitive.

It's entirely possible that Apple takes code or inspiration from the Linux software project, but I think it's better to say that OS X is Unix based. Even if Linux and Darwin hail from Unix roots, at some point, I think they become separate projects with separate interests and fates. What's good or bad for one doesn't have to be the same for the other.

When I think of what organizations will be competing on machine-learning backed features like intention prediction or voice search, I think of Apple, Microsoft, or Google. Those OS features won't be inside the OS. They'll be backed by a wealth of proprietary data hidden behind company servers.

I think user expectations for what a modern OS ought do will evolve, and I don't think Canonical or Redhat will be able to catch up to Microsoft, Apple, or Google.

Eventually, what we think of "Linux OS" will be Android (and if you want, OS X) and maybe some other offerings by these big giants, but the most user-demanded features won't be on the OS. Therefore, Samsung can't just fork Android and expect to compete sans Google, and Canonical or Redhat won't be able to compete either.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#132
post #113

Earlier quoted context omitted.

But that doesn't actually exist by default, and so it's not a good example. A better example is that `/` is a special case for `rm`. (Besides: I'm not a fan of `rm -i`, precisely because it's non-default. You'll get used to it, and then someday you accidentally some files on a system where you didn't add the alias.)

Lots of GNU/Linux distributions used to it by default, has it changed?

None I currently use (just tested with bash* on: Debian, Centos, Fedora, OpenWRT) or have used in the past few years (Arch) has it.

I don't remember anything about my time with SUSE and Ubuntu, thats way back.

* I normally use zsh with grmlzshrc and nearly no customization (which is why I love grmlzshrc -- usable defaults), which warns for `rm -rf foo/*` but not for `rm -rf foo`.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#133
post #113

Earlier quoted context omitted.

Lots of GNU/Linux distributions used to it by default, has it changed?

None I currently use (just tested with bash* on: Debian, Centos, Fedora, OpenWRT) or have used in the past few years (Arch) has it. I don't remember anything about my time with SUSE and Ubuntu, thats way back. * I normally use zsh with grmlzshrc and nearly no customization (which is why I love grmlzshrc -- usable defaults), which warns for `rm -rf foo/*` but not for `rm -rf foo`.

Maybe I am wrong but I think Red-Hat, Mandrake and SuSE used to do it.

Nowadays I spend most of my time in Windows and mobile OSes to remember it properly.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#134
post #11

Earlier quoted context omitted.

Because everything is a file in unix derivative land. That is a common accepted practice at least but optimizing for the common case here is the right thing to do. How often do people need to manage EFI things through the filesystem and how much of an inconvenience is it to have the initial mount be read-only? The answer is obvious to me because I know people run `rm -rf` often enough that having a safeguard in place…

A file maybe, a filesystem no. You can't 'ls' your network connections. And for tricky API that does not match the filesystem view we have the fnctls.

> You can't 'ls' your network connections.

You sure can in Plan 9. Unfortunately (?) Plan 9 is more Unix than Unix itself.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#135
post #124

Earlier quoted context omitted.

On the other hand I was happy and welcoming of systemd then I started to experience way too many breakage due to attitude of the devs. When you have to spend 2 days to get to a remote server room and back because suddenly systemd decided that a device in fstab not present at boot would halt boot with error and at the same time the emergency shell was broken and going into a loop of asking for credentials, on a debian…

Oh my, that is bad indeed. Apart from the two-item sample of personal experience I am kind of torn about systemd - some of the problems it attempts to address are real, and addressing these in general seems like a good idea. The way it does so, however, sometimes (I am being deliberately vague here) brings along some problems of its own.[1] And the further systemd adoption and systemd's mission creep go along, the ha…

> I have not experienced any of these problems myself

That's the problem any time[1] a system is designed around ideological purity.

Someone invents something clever that works most of the time for most people (with varying definitions of "most"), so they try to apply it everywhere. As no idea can account for everything[2], this sooner or later the inflexibility of the theory meets the variation of realty and some type of drama happens.

Usually it's better to avoid anything that exhibits that kind of inflexibility and hubris. Systems that build in ways of handing the unexpected or patching around their own weaknesses are necessary or drama is inevitable.

[1] Not just computer systems - this is true most of the time humans build systems. We see the same problems in religion, politics, and social constructs. It's such a common behavior, I suspect there may be an evolutionary basis for it (using a single common rule for many situations requires less energy).

[2] Even the physicists are still working on that problem.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#136
post #93

Earlier quoted context omitted.

Nobody is saying root shouldn't be able to access such functionality but rather it just shouldn't be mounted rw by default. This is actually fairly uncomplicated.

But then whatever app that runs as root that actually needs to update it is going to remount it rw, at which point the original problem stands. My personal opinion is that, for the use case of a single-user machine (i.e., "Linux on the desktop"), the traditional UNIX root isn't a useful concept. What's actually sensitive is your files, your saved passwords, your browser cookies, your emails, etc.; the ability to reco…

Yeah, and that app isn't rm.

Precisely how many user space apps do you think need access to it?!?

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#137

Earlier quoted context omitted.

Okay, I read the standard and you're right, they are supposed to install to a vendor specific location, so my apologies. Boot's an additional place you can put it, but not the regular place. As an aside, goddamn is UEFI ugly. BIOS it was easy -- set the partition you want to boot as bootable, and away you go. here you have to copy the bootloader file, and then write to the firmware what file you want to boot, which f…

> As an aside, goddamn is UEFI ugly. I was installing a graphics card once and broke my EFI setup. Not because of the graphics card, but because I apparently bumped the CMOS battery enough to wipe settings.

Uh... don't do that?

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#138

Earlier quoted context omitted.

Experimentation, learning, having fun, curiosity, and all the thing that make for a proficient sysadmin.

So cargo-cult? Doing things out of "tradition" without understanding what they are for?

Uh no. Not tradition: experimentation, learning, having fun, curiosity, and all the things that make for a proficient sysadmin.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#139
post #38

Earlier quoted context omitted.

Good.

I could do it in an RPM post-install script too if it will get people to stop whining about running arbitrary scripts. All software you install on your system through binaries is potentially suspect to an extend. Sure, I trust the Fedora build system to do the right thing, so I can with some certainty assume anything in the Fedora Collection or EPEL is "safe" - but when I need to install 3rd party software to get my…

Given you need to be root to install software on an Ubuntu system, a deb could do that also.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#140

Earlier quoted context omitted.

So cargo-cult? Doing things out of "tradition" without understanding what they are for?

Uh no. Not tradition: experimentation, learning, having fun, curiosity, and all the things that make for a proficient sysadmin.

To quote the original post:

> Unix has a long tradition of doing a `rm -rf /` before reinstalling a system. I don't agree with the people saying "don't do that".

So, yes, "tradition".

Post reply on HN