One afternoon (in the middle of the trading day), we got a weird email with an empty body and a bunch of nonsense email addresses. Turns out some poor trader wrote an online dating email (which happened to include the word all) pasted/wrote the mail in the cc line, resulting in all of us learning that he thought “you don’t seem like all the other girls”, which was sent to you@, don’t@, seem@, and the dreaded all@.
We had a single shared T1 pipe for the whole district. Which was enough for email and stuff, but when web browsers got popular, it was suddenly woefully inadequate.
So I figured out I could NET SEND * SERVER ROOM POWER FAILURE - 9 MINUTES OF BATTERY REMAIN - SAVE YOUR WORK AND LOG OUT and after a flurry of traffic, the network fell to nearly-idle. I could max out the T1 with whatever I needed to do for a few minutes, then NET SEND * SERVER ROOM POWER RESTORED and nobody would be the wiser.
The admin did go check on the "flaky UPS" a few times before looking closely at the message. Had a good laugh and told me not to use it too often.
CRITICAL DISK ERROR. TURN OFF SYSTEM TO AVOID CATASTROPHIC DATA LOSS
and then printed it out to a system printer students didn't have access too. So you got a page of random symbols and that error.
Little did I know the company adding more computers to the network was there that day and the guy panicked and had the system shut down, it was down the next day too. I never did ask what happened to bring attention to myself, and this was before we had individual accounts in the system.
apparently "wall" has a switch "-n" to hide the sender
https://unix.stackexchange.com/questions/99460/sending-messa...
for windows there was "net send" which could be exploited by a tool called NetSendFaker, but this was 1991, so i doubt that already existed.
Making write/wall sgid, and restricting tty write access to that group, was a significant security upgrade back in the day.
Another guy wrote a program that forked 1000 copies of itself, nice itself to 19, did a sleep(0) and then exit. As soon as it got any cpu time, it would exit, but it never would as long as emacs was running. Meanwhile, the load (as displayed by xload) became a solid black box.
So the emacs guy would run 'ps -ef | grep procname | xargs kill' as root.
This meant that it had to get some cpu time to handle the kill, which took longer than a sleep(0) and was largely ineffective.
The second time this prank was done, the process was named 'ema'... which promptly also killed all instances of emacs too.
The third time this prank was done, the process was named 'et'. This happened to have also matched /etc/initd and the machine rebooted rather suddenly.
Even though I'm pretty sure I've run with init=/bin/sh and then typed "exit" at some point in my single-user session, I have absolutely no recollection of the results. I should try it on a few OSes and see!
Of course, his method of preparing to move offices (a common occurrence at IBM) was to
1. Take his (RS-6000) workstation home with him the night of the move.
2. Otherwise, just lock his desk.
He didn't have anything in his office but his chair, desk, and workstation.
Sync is not synchronous. When it is back to the shell there is no guarantee that data in memory is fully copied to disk.
However, it sets a flag that is reset when the copying is done. Sync will hang if the flag is set.
So the first sync arms the copy and sets the flag and is back to the shell.
The second sync starts, blocks at the flag. The flag gets reset and it is back to the shell.
So the 2nd sync going back to the shell is a guarantee that the first sync is fine and data is safe
When you have nice, well behaved users you'll not have problems that need solving. When things go awry - that's when you'll need to solve problems... sometimes even without pranks.
Before we had yp set up on the machines, we just copied the password file between them with a note "make sure you change your password on foo" since that was the one we regarded as authoritative and would copy that to bar.
One time, while adding a person to the /etc/groups file for write access to the web server, someone did rcp /etc/groups bar:/etc/password (I suspect it was muscle memory) and, well, now bar was unhappy and wouldn't let anyone log in... or even su to root to fix it. Found someone who had an open terminal and had them do a while 1 sync... and then powered the machine down and brought it back up. It wasn't happy, so started up in single user mode. Just needed to get the password file in there... but the terminal was 300h which didn't have a proper termcap entry for vi or emacs to work. I was a mudder and knew how to use ed... so ed /etc/password and then the contents of the minimal password file were dictated to me. When done, we got it back up and then copied the password and groups files to the proper spots.
Another time (and this was a prank), someone left themselves logged in and someone else created a directory path that was about 3000 characters long. /user/jsmith/I/will/not/leave/myself/logged/in/I/will/not/leave/myself/logged/in/ ... The problem with this is that `rm -rf` won't handle paths longer than 2048 characters long. So it didn't get removed "I'll do it later." You know what else doesn't like paths longer than 2048 characters long? fsck. So when the machine was rebooted/crashed at some point, the root volume (yea, user directories were on the root volume) failed to fsck... and failed to mount. Stuck in single user mode with the backup partition and reading the man pages for mount on the other machine we found how to force a mount without fsck and then had the guy who did the extremely long path fix it (and promise not to do it again) and got machines working.
NeWS had an interactive PostScript shell and almost no security so this kind of mucking about was trivial...
Unfortunately, it broke some pages that lab users needed for school. I later learned one colleague wasn't able to complete a homework assignment because of my prank.
It amazes me what the bios and OS or OS api's let you do, even on modern devices.
Same, but not necessarily in a negative way. I like pushing my hardware and software to the limits, becoming unable to push those limits would be pretty disappointing.
VMS has a very comprehensive system of quotas and limits, so a "properly" configured system wouldn't suffer those issues.
And furthermore, VMS isn't intended to be used "interactively" as such. You should be submitting work to the built-in batch queues - each with various attributes that can include the priority level. This allows the system to intelligently manage work based on a comprehensive view of the entire system - something a single user in a multi-user system can't have. If you like pushing a multi-user system to its limits, you'd be impressed with what VMS could do even way back in the 1990s.
I mean, our motherboard has an external clock generator almost entirely dedicated to pointing and laughing at CPUs with a "locked multiplier". (It's also used for PCIe 5.0)
-Emily (see HN profile for details)
Overclocking. Profile explains why. For security I prefer single cores, but have to work with whats available.
Not sure whether you're referring to your or our profile, but yes, we do overclock to a significant degree. Our motherboard has a setting to downgrade the CPU microcode to an older version that doesn't try to detect higher clock speeds and shut down. Clearly, stuff is already getting more and more locked down even as we enjoy our relative freedom in the present.
-Emily
Isn't pretty much every "cloud" nothing more than an elaborate multi-user system?
*ignoring all the system and service users in OSes like Windows and Linux.
-Emily
Its a problem I'm facing at the moment, trying to keep the data as it moves around the hw, tamper proof.
Intel CPUs are designed with certain characteristics, which can highlight thread priority attacks.
Cant comment on ARM or AMD yet, havent tested them.
Happy System Administrator's Day!
Unfortunately the fg part of the equation was lost on about 2/3 of our class... after editing they would start another scheme instance! I recall being in the terminal lab the night one of our first assignments was due, and the machine slowed to an absolute crawl. Can't remember exactly how it was resolved but I do recall being taught how to look for classmates running two or more instances of scheme to remind them about fg. (Also not helpful to machine load: "solutions" to the 8 queens problem with infinite recursion. The real lesson here was, in later years, to not be logged in on nights when CS 401 had assignments due.)
Luckily I worked almost entirely over ssh so I presume the suspended threads died with my ssh session exiting each day.
I'm not sure where he worked but it involved a queue of people. He said someone asked him if they could be given priority for their problem to be looked at before others in the queue. In other words jump to the head of the queue.
He said "Sure!" to the surprise of the person asking "But you do realize I will do that for anyone else who asks the same thing?"
So they person chose to remain in their place in line.
Digging into the manuals I figured out how to launch the compiler as a background process so I could still have a working system while waiting for it. Brought the whole classroom to a halt.
More digging revealed that the background priority was set well above user priority. AFIAK no malice involved, just someone who didn't know how to set the system up and left that landmine for me to find.