With physical access, sure. The same could be said for shutdown with physical access. Nothing stopping the user without group membership from holding down the power button or unplugging the kettle cable.
In the UK and Ireland (and maybe elsewhere?), a kettle lead is actually C13. I guess you need a beefier cable/pins in the US, as you're drawing more current at a lower voltage.
Most kettles now have a base with an integrated cable though, so the name doesn't really correspond with the cable's most common usage any more.
>I guess you need a beefier cable/pins in the US, as you're drawing more current at a lower voltage.
No, we just accept slow-as-piss kettles.[1] (Our plugs aren't great, either, it's pretty common for a spark to jump the gap of the leads while you're plugging it in.)
High wattage appliances here have an effective max of like 1.8kW on a single-phase 120V outlet, it makes for pretty useless space heaters and kettles. You could probably beat our kettles with an induction cooktop just by virtue of the stove being able to use two phases.
Truly it's a tragedy for those of us addicted to our hot beverages.
>it's pretty common for a spark to jump the gap of the leads while you're plugging it in.
how are you plugging it in? Are you plugging the mains end into the wall before you plug the kettle end? That's truly bizarre to me, and goes against everything
> it's pretty common for a spark to jump the gap of the leads while you're plugging it in
If you’re referring to seeing a spark while plugging something in, that’s just current jumping from the socket to the pin that’s entering it - it’s nowhere near possible for current to jump between the pins on a single plug (in air, at least). The distance between pins was specifically designed to prevent that possibility at the given voltages.
Not saying our plugs aren’t poorly designed, just that that’s not one of their problems.
I had a friend who was easily teased by this, but he was quite right, and you are wrong. Kettle leads in the U.K. have never been C13, and "kettle lead" for a C13 power lead is a misnomer just as much in the U.K. as it is elsewhere.
When kettle power cords weren't captive, as they are nowadays, they weren't C13. Non-captive kettle cords from the middle 20th century were round pin, for starters, and not like the (later) IEC standard at all. Here's a round-pin electric kettle from the 1960s, for example:
That first link doesn't support your point. No one would claim that all kettles ever sold in the UK have C13 cables. (No one would even claim that none use C15 – after all, some companies will surely just use the same design across all markets if possible.) This particular kettle is before C13 and C15 were even standardised.
The website it's from has a fair number of kettles from the relevant time period (1980s and early 90s). These two (which seem to be variants of the same model) [1,2] have an OKish view of the power connector and look more likely to fit C13 than C15 from what I can make out (no notch). This one [3] is clearly for C15 though, but as I say it's not a surprise that some exist.
On the contrary, it supports exactly the point made in the preceding paragraph, which even pointed out that the IEC standard came later.
The phrase "Should have gone to Specsavers!" comes to mind. All three of your examples clearly have notched connectors. Two have the notches at the top, and the Russell Hobbs one has the notch at the bottom. Their kettle leads were not C13.
So to repeat: When kettle power cords weren't captive, as they are nowadays, they weren't C13. I've already given an example of a kettle preceding the standard that didn't take anything like a C13 connector, and in vainly arguing against that you've ironically produced three more examples of kettles from later decades whose kettle leads were also not C13.
Here's yet another one, where the lead itself is in the picture. It's not C13.
If there had been examples of kettle leads that were C13, I'd have long since used them to really tease my late friend. But kettle leads in the U.K. have never been C13, and my late friend was right that "kettle lead" for a C13 power lead is a misnomer in the U.K..
I think its just the UK and Ireland where there's a demand for "high performance" kettles. The rest of the world is condemned to waiting longer boiling periods due lower-wattage kettles. I've had a British expat audibly exasperated by my kettle.
A little fun from time to time doesn't hurt too much, does it? HN can certainly sometime bring us a smile. My "you managed to make me smile" message has been upvoted 21 times so far.
It's not a slippery slope, it has always been like this. If it were everywhere every time it would be annoying, but it's not the case.
but the irony is that i'd prefer if someone trying to shut down my computer they would use ctrl-alt-del to initiate a clean shutdown/reboot instead of just pulling the power. in fact, if my GUI is stuck somehow, i'd want that for myself too.
"This isn't DOS" is rather inconveniencing myself for the sake of purity. i have been there too when i was young.
> As network technology has improved, the limitations of PXE Boot are more apparent. PXE has no mechanism for encryption or authentication, is susceptible to man-in-the-middle attacks, does not scale outside of local networks, and has reliability issues associated with TFTP time-outs and UDP packet loss.
[snip]
> One of the key issues with PXE is a lack of security. The TFTP & UDP transactions associated with PXE may be the last unencrypted traffic on your network and are trivial to intercept. This boot process goes against the “zero trust” concept applied to today’s networks.
However, UEFI to the rescue:
> The UEFI Specification introduced HTTP(S) Boot in in version 2.5. HTTP Boot combines the Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Hypertext Transfer Protocol (HTTP) to provide system deployment and configuration capabilities over the network. Compared to PXE Boot, HTTP Boot can handle much larger files than TFTP, and scale to much larger distances. PXE depends on UDP broadcast You can easily download multi-megabyte files, such as a Linux kernel and a root file system, from servers that are not on your local area network.
Where did you get the idea that anybody on the Internet can?
The first step to network booting (PXE or UEFI boot) requires DHCP, which means a DHCP server or relay on your local broadcast domain (switched LAN, and I'm sure there are extensions for boot-over-WIFI somewhere).
Sure your computer could fetch the boot image over the Internet, if you're okay with involving the unreliability of the Internet in your boot process, but that'd require explicit configuration on your DHCP server.
Using DHCP, the same tool that can configure any client computer with addresses and gateways, meaning you hopefully secure that already.
Some switches give you tools to mark a few physical ports as "truster", allowing DHCP OFFER from those; and drop (or ever shutdown the port!) when such a packet is received on an untrusted port.
I always thought the one-group-per-privileged-action-or-device model could have been taken farther than it was rather than diving into ACLs and capabilities (which IIRC OpenBSD doesn't support anyways) or the various -kits. Is it just that it's an absolute pain to administer, or is there a deeper problem lurking there?
The problem is that organizations don't want to be told by computers to just use sane and logical structures for their meatbags, they'd rather spend billions on making the computers compatible with every single deranged edge organizational case that only exists because of 20 years of unmitigated office politics and/or warfare.
On the plus side, most of IT would be redundant if they ever smartened up, so let's hope they continue to wage their little wars through IT procurement.
Contrast that to how OpenBSD handled this. There was a thing, disk access, that shouldn't be allowed to those who could shutdown/reboot, so they bounced it around internally for a while, then de Raadt submitted a patch that said, "we're doing it this way, our users will figure it out, it's not a complex thing."
No massive re-architecting, just add a group, done. Businesses could learn a lot from the way the *BSDs and Linux do things. They're all different, but you can't argue with the results.
I actually think, given how the usage share of the BSDs is a fraction of that of Linux or Windows, that OpenBSD is a textbook example of how "good enough" almost always trumps technical excellence.
Linux is unquestionably less "cohesive" and "organized" than BSD but I can't think of any reason to reach for BSD given Linux exists.
"Is it just that it's an absolute pain to administer, or is there a deeper problem lurking there?"
Deeper problem. Authorization in the general case can not be done with a set of simple textual tags. Consider sudo. A group might be able to flip on or off whether or not you have generalized sudo, but if I want Bob to be able to run these threes scripts, Betty to be able to run anything as root, and Billy to be able to run this exact script with this regular expression validating the argument, how are you going to do that with groups?
Obviously, you can use groups in the solution (each of those names can be replaced with a group identifying a set of people instead of an individual name), but you can't be creating an OS-level group for every tiny fiddly permission that may exist somewhere on the system, especially in contexts where the groups are shared across an organization.
Or, to put it another way, yes you could take any arbitrary policy and compile it down into a final set of tag-based permissions, but nobody would want to deal with the resulting thousands/millions of little group tags. It is technically possible but not a win on any level. For example, would you prefer an ACL that says you can access some resource during business hours, or an appearing and disappearing group tag?
ACLs and capabilities may suck in some ways, but a quite significant amount of the suckage is fundamental to the problem space. As humans we just don't want to be that specific about security.
> nobody would want to deal with the resulting thousands/millions of little group tags
But... you have to? You can hide it behind polkit or ACLs or capabilities or whatever but you still have to actually specify the logic.
It's something I'm still annoyed about as we port a realtime application to rtkit: it's the exact same limits you used to have to establish in /etc/limits.conf but now they're in a different place. That doesn't actually simplify anything; you still have to establish the same limits.
If I recall correctly, all system groups should have a leading underscore for OpenBSD. However, they make exceptions for groups that have been around long before this became their standard.
Yeah thanks, I edited that like 10 times dealing with escaping the asterisks with backslash, adding the two spaces, removing the escaping, newlines, etc :)
It's probably to avoid conflicting with potentially existing user-defined groups. The underscore in the C/UNIX world has an intrinsic meaning of "implementation reserved", so it's your fault if the new group conflicts with one you improperly created yourself.
It's to set system applications' resources aside, and it's more of an OpenBSD thing than a *BSD thing. Once in a blue moon you'll see it in the Linux and general *nix world as well:
I wonder if the endgame is that each suid binariy will have separate group associated with them. I don't have obsd at hand, what the situation is like currently?
OpenBSD is unique amongst the BSDs in that its halt(8) and reboot(8) commands use the rc(8) system to shut down services gracefully, so the only thing you're missing is scheduling and shutdown message broadcasts.
Elsewhere those commands simply broadcast SIGTERM/SIGKILL to all processes, so you should use shutdown(8) unless you're in single user mode.
poweroff(8) has halt/reboot semantics on NetBSD, but shutdown semantics on FreeBSD/etc.
For those unaware, Undeadly.org is a very unusually engineered site. It's written in C, and it runs under FastCGI on OpenBSD's (edit: home-grown) httpd.
> it runs under FastCGI on OpenBSD's fork of httpd.
FWIW, OpenBSD hasn't used [a fork of] Apache in nearly 10 years. Since OpenBSD 5.6 /usr/sbin/httpd has been a homegrown HTTP server, originally based in part on relayd, an HTTP proxy and another bespoke OpenBSD project. OpenBSD httpd can only serve static files or forward requests to a FastCGI handler.
Now, this is surprising. I randomly clicked on that link and I immediately see that the code and the patch has a bug. It only checks the first 8 characters:
> "A trivial silly mistake like this is... not what I expected considering OpenBSD's reputation for security."
Forgetting that "_shutdown" is 9 characters is definitely an oversight on their behalf. But you need superuser privileges to create groups, and at that point you can also just toss any user right into the regular _shutdow(n) group.
There's not really anything to exploit here, but if this type of comparison is present in other software - whether OpenBSD's system tools or not - I can definitely see how it has a general potential to cause a sysop to accidentally "cross-pollinate" his or her users, e.g. "ftpuser<some digits>".
Is this not just a cosmetic thing? Xfce wants to know if you have shutdown permissions so it can render the right buttons for what you can do, but so long as the code isn't running privileged it's not actually going to let you do anything — it'll just run /sbin/shutdown fruitlessly.
It's in the OpenBSD ports CVS tree, as can be seen by the fact that it's adding the file `x11/xfce4/xfce4-session/patches/patch-xfce4-session_xfsm-shutdown-fallback_c` and `/patches/` means it's part of the OpenBSD-specific `ports` infrastructure.[0]
The change might be submitted and accepted upstream in the future, but I think it's hard to justify this particular change as not being part of OpenBSD at the moment.
If OpenBSD had specified that groups are only unique up to 8 characters, wouldn't they avoid to specify a "_shutdown" group of higher length?
Looks like an overlook to me. Double click on operator, yank, type the new group name, done. Or even a quick replace all not noticing there was an hardcoded length right after one of the occurrences. The parent might have found an actual issue.
But happy to join you in the "maybe I just don't get it" clan.
You still need to be root to create groups and assign them to users, so probably not a big one and it will probably work all the time in practice.
How funny is this, someone randomly asks for the diff on HN for no apparent reason, someone else gives a link, someone else randomly opens the link and finds a potential bug.
Looking back at the change after lunch it does seem like it was a rename without realising the strings were a different length. Actually changing "operator" to "shutdown", confirming the length was the same and didn't need to change, then realising it needs to be prefixed with "_" but not updating the length param would explain this nicely.
This prints the numbers 9 and 10 (on gcc I have). So if you used `sizeof(...)+1` when calculating the length argument for strcmp you'd be comparing the 9-byte string, the null terminator and one character of random nonsense.
you'd want strlen("_shutdown")+1, since checking without the null-terminator means that you match with strings like '_shutdown123'.
It's one of the reasons why I detest the strcmp warning, as strcmp is perfectly safe given a literal string as a comparison, the comparison will drop out as not matching whenever the first NUL happens, and a literal string acts the same as specifying 'n'. Blind usage of strncmp leads to perhaps even more bugs than blind usage of strcmp.
It also previously matched operator9000, so the intent was obviously a simple prefix check, and thus preserving that behavior is essential to avoid breaking userland.
