Funny story. When I was in grad school, the math department office I was in had Linux computers administrated by the department. One day I was goofing in my shared office with a fellow grad student by playing with what resources were available.
We were trying sudo and failed with enough silly passwords that we got the "this incident will be reported" message. I confidently told my officemate that these messages were never saved and recorded.
A few moments later, from our open office door (which I assume meant all our conversation was able to be overheard), our IT lady from down the hall came in and said to me "Download the internet, really?"
Because yes, I did type, while not saying I was doing so, "sudo DOWNLOAD THE INTERNET" into the terminal while goofing.
Funny story but I did feel a bit embarrassed at the time.
I find it bothersome that the "yes" command outputs "y" by default instead of "yes". False advertising! Since Unix loves short concise command names, why not just name it "y"?
That was such a mind blowing experience coming from a DOS background. It would split your terminal horizontally and you could see each other type in real time.
Before the days of SMS, and even before the days of instant messengers like ICQ and AIM, I taught the split-screen `talk` command to my girlfriend so we could chat while I was working. We've been married for 20 years now.
The one program truly blew my mind at the time was Netrek - the first networked multi-player realtime graphical space fighting game. I've wasted so much time late into the nights playing the game in the lab instead of doing coursework.
The admin came to the lab from time to time and said we're hogging the workstations with the game and banned the game during daytime.
I remember ca. 2000 my best friend busting into my office, pushing me aside, logging in savagely to something and having a sight of relief.
He managed to send back a fleet or something - it was a real time game where you needed to do stuff at the right time (after sometimes a few hours). I do not remember the name of the game but it was fashionable for some time (not sure if it was text based or not)
Those games are still kicking around. Played Neptune's Pride a while back, would not recommend, seems designed to devour your waking (and what should be sleeping) life.
It's a fast paced multi-player space battle game with a top down graphic 2D view. It's like Command and Conquer, with each unit controlled by a different player.
"talk" was often bugged (and IIRC, used UDP) so it was soon updated by xtalk and then ytalk. ytalk was like the kitchen sink of talk, with a huge feature set and compatibility with everything that went before. Everyone had to get ytalk for sure.
Oh man, that brings it back! ytalk on the university student server was just about the first instant messaging system I used. My typing speed went way up after a few weeks.
Long before Unix talk, ITS (the Incompatible Timesharing System at the MIT AI Lab) had a program called UNTALK, written by a user named UNCOLA, that supported split screen text chat, back around 1992 or earlier.
Getting Started Computing at the Al Lab by Christopher C. Stacy. MASSACHUSETTS INSTITUTE OF TECHNOLOGY ARTIFICIAL INTELLIGENCE LABORATORY WORKING PAPER 235 7 September 1982:
>If you want to link to someone who is on another ITS machine, you can use the TALK program. The program is run by typing:
>*:talk uname@host
>To exit TALK terminating the conversation, the user who initiated TALK must type ^C.
>This method of comlinking is less versatile than the backnext commands, and only works across ITS machines (not locally).
>Another useful comlink program is UNTALK. UNTALK is similar to TALK but does not work across machines. However, on a display terminal, UNTALK splits the screen horizontally and allows the two people to type at the same time on their part of the screen.
The "backnext commands" he referred to would actually let you not only perform a text chat link (albeit not split screen), but also take over another user's TTY, to type into and see the output of their DDT shell and programs. There was no security other than obscurity on ITS, and that feature of linking to and sharing another user's TTY was meant for collaboration, helping, and teaching people, and also initializing and configuring output-only serial devices like line printers.
History of the Net is Important, by Keith F. Lynch:
>[...] ITS stood for the Incompatible Time-sharing System, an obvious take-off on CTSS, the Compatible Time-Sharing System. (Just as Unix is a take-off on the earlier TENEX, TWENEX, and MULTICS.)
>All four ITS machines also had UNTALK, a split-screen conferencing program similar to the later “talk” on Unix and PHONE on VMS. I was told it was written by a user whose ITS username was UNCOLA and who had committed suicide. I don’t know if it was the first program of that type, but it was the first I had seen.
Even before that, ARPANET TIPs supported a low level way of text chatting (not split screen) called a "TIP to TIP Link" (documented on page 5-4 of the "Users Guide to the Terminal IMP") where each participant bounced their packets off of a port on some host, without actually logging in or going through the host.
I did a summer program at MIT around then and remember a program that let you send popup messages in xwindows to other users or to a channel. You could subscribe to any channel and use wild cards. I remember being hacked by someone to subscribe "*" and being unable to use my terminal for a while until i figured out how to unsubscribe without being able to see what i was typing under the wall of messages. I thought it was called zyphermail but the interent seems to have no memory of this.
Back in the days of ARPANET mailing lists, there used to be an "educational" mailing list called "please-remove-me", that was for people who asked an entire mailing list to remove them, instead of removing themselves, or sending email to the administrative "-request" address.
So when somebody asked an entire mailing list to remove them, somebody else would add them to the "please-remove-me" mailing list, and they would start getting hundreds of "please remove me" requests from other people, so they could discuss the topic of being removed from mailing lists with people with similar interests, without bothering people on mailing lists whose topics weren't about being removed from mailing lists.
It worked so well that it was a victim of its own success: Eventually the "please-remove-me" mailing list was so popular that it got too big and had to be shut down...
...Then there was Jordan Hubbard's infamous "rwall incident" in 1987:
You might be thinking of Zephyr, which was part of Project Athena. My school was using Athena, and I occasionally received zephyrgrams from people at MIT.
I remember that one of the financial banking software we were using had an internal chat that was basically using "write"(?) underneath to send messages to another users terminal (it was running on Sun Solaris I think).
When I started college, all of our classes would assign a temporary (semester-long) account on one of the various Vax 11/780s supplied by the computing center.
Talk wasn't available yet (pretty sure we were on 4.1 BSD), so we'd use write(1) to communicate to each other (e.g., to figure out where someone was sitting in the lab). To block someone from writing to you (often desired, because write(1) would just spew over whatever you were currently looking at), you'd use the "mesg" command, which our University set as default to 'y'. I figured out that running 'mesg y' effectively just gave open write permission to your tty.
With that knowledge in hand, I started a practical joke where I'd remap someone's keys by redirecting an stty command to their tty, e.g.:
% stty erase e > /dev/tty03
which would make 'e' the backspace key for the duration of their terminal session. Much hilarity ensued.
It always annoyed me that the Unix terminal subsystem is too dumb to handle multiple writers to the same terminal at once without them potentially corrupting each other’s output. There are some techniques to reduce the incidence of this but none of them are foolproof, whereas a better design could be.
Maybe that was too hard when people used to use hardcopy terminals (actual ttys), although even there it possibly could have done better than it actually does.
But certainly by the time people had softcopy terminals with cursor positioning (like the DEC VT series and its emulators), a better experience could have been possible. For example, what if the functionality of curses was actually in the tty driver, so if another process wrote to the terminal it would appear as a new window, which could then be dismissed without altering the output of the underlying program? Or, to avoid putting too much in kernel space, the tty subsystem could live in a user-space daemon (possibly one process per terminal), and then applications would talk to it over IPC
>Or, to avoid putting too much in kernel space, the tty subsystem could live in a user-space daemon
On Unix, that's what "pseudo ttys" are for (i.e. /dev/pty*)!
For example, that's how Emacs lets you run multiple shell sessions in sub-processes, such that they have full job control (i.e. ^Z and ^C works to interrupt or stop sub-processes in the shell, since they're handled by the TTY). That's also how xterm and the Mac Terminal emulator work, providing the shell sub-process with its own pseudo tty with job control, even though there's not a corresponding /dev/tty* serial port driver. It's like a virtual serial port using a device driver with "TTY Line Discipline" but without an actual TTY.
ChatGPT correctly explains it better than I can or anything I can find with google:
Unix pseudo ttys, or pseudo-terminal devices, such as /dev/pty*, are a key mechanism in Unix and Unix-like operating systems for enabling communication between different processes. Pseudo-terminals are designed to provide the same interface and functionality as physical terminals or terminal emulators. They consist of a pair of devices, the master side (e.g., /dev/ptmx) and the slave side (e.g., /dev/pts/N), which are used to establish a bidirectional communication channel.
Pseudo-terminals are useful for running programs that expect to interact with a terminal, even when there is no actual terminal involved. This is particularly important for terminal-based applications like Emacs, which can run sub-shells within their own window or buffer.
Emacs, an extensible and highly customizable text editor, can leverage pseudo-terminals to run sub-shells, like bash or zsh, within its own environment. [Omitted detailed instruction on how Emacs sets up a pty for a sub-shell.]
By utilizing pseudo-terminals, Emacs can provide an integrated environment where users can work with both text files and interactive shell sessions seamlessly. This enhances productivity and enables users to harness the full power of Emacs' editing and navigation features while working with the shell.
> >Or, to avoid putting too much in kernel space, the tty subsystem could live in a user-space daemon
> On Unix, that's what "pseudo ttys" are for (i.e. /dev/pty*)!
No, that’s not what I was talking about. On just about every Unix, even with ptys, the line discipline code (or STREAMS modules for SysV-derived systems) still runs in kernel mode.
On Linux, you could implement something like what I was talking about with CUSE - have a character device which implemented the termios ioctls in a user-space daemon instead of in the kernel tty driver. That’s very different from how most Unix systems implement ptys
But what I was actually thinking about was a daemon which exposed over IPC an API a lot richer than termios. Something closer to curses.
Back when I was at university the x servers on our terminals were not secured, and other people could open output on your terminal. A favourite was a program that sent cockroaches scurrying around the screen whenever you moved a window.
My university got a bunch of SGI Indy's for cheap as a marketing ploy by the importer, and everyone could log in to all the machines. It became a lot of peoples first experience of the privacy implications of webcams (they had them built in) and taught a lot of people the value of paying attention to the privacy covers.
Jordan Hubbard wrote: "One of the people who received my message was Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he wasn't exactly pleased. (I hear his Interleaf windows got scribbled on)"
>Here's the explanation he sent to hackers_guild, and some replies from old net boys like Milo Medin (who said the program manager of the Arpanet in the Information Science and Technology Office of DARPA Dennis G. Perry said they would kick UCB off the Arpanet if it ever happened again), Mark Crispin (who presciently proposed cash rewards for discovering and disclosing security bugs), and Dennis G. Perry himself:
>Actually, Dennis Perry is the head of DARPA/IPTO, not a pencil pusher
in the IG's office. IPTO is the part of DARPA that deals with all
CS issues (including funding for ARPANET, BSD, MACH, SDINET, etc...).
Calling him part of the IG's office on the TCP/IP list probably didn't
win you any favors. Coincidentally I was at a meeting at the Pentagon
last Thursday that Dennis was at, along with Mike Corrigan (the man
at DoD/OSD responsible for all of DDN), and a couple other such types
discussing Internet management issues, when your little incident
came up. Dennis was absolutely livid, and I recall him saying something
about shutting off UCB's PSN ports if this happened again. There were
also reports about the DCA management types really putting on the heat
about turning on Mailbridge filtering now and not after the buttergates
are deployed. I don't know if Mike St. Johns and company can hold them
off much longer. Sigh... Mike Corrigan mentioned that this was the sort
of thing that gets networks shut off. You really pissed off the wrong
people with this move!
>Dennis also called up some VP at SUN and demanded this hole
be patched in the next release. People generally pay attention
to such people.
Jordan's infamous rwall incident is the kind of thing that might have triggered the rumored "explosive bolts" the Defense Communication Agency was once talking about installing, that would violently separate the MILNET and ARPANET in case of national emergency.
>DCA must have the ability to partition the ARPANET and MILNET in
case of an "emergency", and having non-DCA controlled paths between
the nets prevents that. There was talk some time ago about putting
explosive bolts in the mailbridges that would be triggered by
destruct packets... That idea didn't get far though...
Speaking of interaction with the admin. Back in the days when I was in school, the computer lab ran a Honeywell mainframe with terminals. I wrote a program emulating the logon screen to intercept the username and password of the unsuspecting students logging on and to email them to me. I was going to post the list of all the usernames and passwords at the end of the semester on the wall. I dubbed it the Fishing project with my friends (yes, that's before all the phishing activities went rampant).
I collected dozens of usernames and passwords before the professor of my CS class stopped me one day after class and said, you better stop whatever you're doing. Apparently the system saved the typing of all sessions and the admin actually went through all of them.
The next semester all the terminals had a physical switch installed that had to be pressed to reset the terminal before logon. That killed any running program. I was glad to play a small part in improving the security of my school lab.
That’s quite similar to my story. While at high school, I wrote an innocent program to open the terminals at the nearby college for chat sessions - nothing nefarious. The sysadm saw what I did and realised I could use it to phish passwords. Next time I went to use the computer lab, the terminals were locked down.
Showing my age but this would have been 1984 or so… a remarkably early contribution to security?
This is more or less how I started to administer the unix cluster at my uni in 1993 as a student.
I wrote a fake su program that woul d impersonate the real one, asked the admin to help with something, got the root password and went to them to tell them the password a few days later.
And offered my help in exchange of a seat at their shared office and my own workstation. They were glad to get someone because unix was new to them (they were using Novell). It was new to me too but I learned a huge amount of things that were actually bootstrap my IT career after my PhD.
I am 100% sure I had some petty manually-initiated retaliatory action taken against me by a sysadmin at my university. I never heard a peep through any channel, official or otherwise.
I got a chiding lecture like that from some skinny UUG-type security admins, by manually shutting down my HP-UX workstation in a university CS lab. I had reached behind it and flipped the power switch.
I tried to flip it back on just afterward, to resume my business (lol) but found that my login was blocked with a message...come up to security in room 300-something and talk to us to get your account un-suspended.
The issue leading to the frantic shutdown goes as follows:
I had been browsing some of JWZ's online journals in Netscape...the old about:jwz trick.
Within those pages, there's a linked audio clip of the fake *rgasm scene from "When Harry Met Sally".
I clicked on the link not realizing what would happen, and of course this passionate audio clip played at more or less full volume to a computer lab full of university students from China.
(They were extremely "I didn't notice that" about the whole thing, but I was beet red and frantically scanning the room for anyone who I could possibly nervously laugh with...)
Back then Netscape didn't show any audio controls that I could find anywhere when clips like that played, which was also a really frustrating part of this. I guess it just handed off the audio to some process which I could have found via `top` if I had the time.
There was also an internal speaker, nothing with a manual volume control. Great!
Anyway, I went upstairs, got my lecture about other people who could have had sessions terminated while working on the same workstation, got the login back, and fortunately none of the Chinese students seemed to have let my er..._BYU_ CS security admins...know about the situation in the lab. lol.
(No longer a practicing Mormon; still think CDE is cool)
Edit: Just for the memories...at the same time, I had a PT job doing university IT support on a Novell network, and we supported, among other places (the MTC, the laundry, Creamery--PHEW those amazing chocolate malt shakes--but not so phew the time the creamery's huge 1K+ gal. milk vats leaked and there was a foot of standing milk in our PCs there, etc.), the married student housing computer labs.
Colloquially labeled by my boss and others as the "rabbit hutches"...
This was still pretty early days for the web, and I remember periodically getting frantic voicemails from newly-married folks.
A common version of the voice message would be something like, "Hi, uh...I was in the married student housing lab...trying to book airline tickets for my husband to fly home and see his mom...anyway (tearful quivering voice starts)...russian porn came up I guess? I mean I am just guessing...uh, so anyway...(crying harder, phew)...the lab assistant gave me your number, and here's my number, if we need to talk about this or anything, call me I guess?"
I can't imagine what those students must have felt when the lab assistant just shrugged their shoulders regarding "what to do about this" and gave them somebody's office number to call. Up the chain with you!
Gestapo-level perceptions would always tend to kick in at that point...and you had to maintain an ecclesiastical endorsement to continue studies there, so this was a pretty big deal. Anything involving porn was always at the potentially-terminate-your-entire-university-experience level.
(Often the calls to those labs were pretty funny though. Like a toddler put a dorito inside of a CD-ROM drive, bring your hemostat, things like that. Afterward we'd get a Jamba Juice, or get a free cafeteria meal from a really nice food-services manager, chat about Everquest, etc.)
This is an interesting example of the Clever Hans Phenomenon. You think you're comparing GPT and Google equally but you're actually giving GPT much more manual help. A search as simple as "UUG acronym" gives me the answer in a box at the top: "Unix Users Group" (tested in incognito).
GPT is useful, but there's an annoying tendency of it's proponents to promote it with examples they haven't validated.
Interesting. The same search term returns "UUG is an acronym for: Uniface Users Group. Universal Underwriters Group." in the top box for me. Also in incognito.
This user group was already in place by the time Linux came along, so you had the UUG doing Red Hat boxed set giveaways and such. There was a ton of excitement about Linux and not as much about Unix at that point. Then a bit more proper-Unix excitement when OS X came out.
I got my uni CS club going on IRC. I’ve recently discovered that they’re now on Discord. I get it, like, IRC is increasingly undesirable these days, especially without a bouncer. It still hurt though.
Also former BYU EE major (and former Mormon), very early 2000's. I recall fondly those HP-UX boxen running CDE. I really liked that UX. For some reason it really appealed to me as an engineering student. I was very active in the UUG. At one point I lived in a married student housing unit. Some of the kids fucking incessantly in those units could have stood to make sure their windows were closed. But I digress. Story time!
This was in the early days of Napster. Out of curiosity I downloaded and unzipped it in my home directory. I think I started downloading some random file but terminated it before it finished. Several weeks later when trying to log into my account, it didn't work. When I asked the skinny kid in the admin room about it, he lectured me about having the Napster software unzipped in my home directory before telling me to delete it as he re-enabled my account.
I was generally low-trust when it came to anything administration-related at my school, so I kept my own backups of all my shit. That ended up saving my ass. The HP-UX boxen were configured to dump huge core files by default on segfaults. The predictable thing happened as random widely-ignored core files proliferated throughout student home directories. I think about 2 weeks before the end of the semester, some low-level admin kid tried writing a script that recursively walks all the students' home directories and deletes core files to free up disk space. Not wanting the script to interfere with regular workloads during the day, he had it run as a cron job in the middle of the night. The kid fucked up the script, and it instead deleted all the contents of everyone's directory for the whole goddamned department. Well, effectively. I think when the admins got into work the next morning they realized that shit was completely fucked and killed the script. But massive damage had already been done. Two weeks before the end of the semester when final class projects were all coming due. Also, the backups hadn't been working, and nobody had been giving a fuck. Until then.
I had a friend in another lab in the CS department who ran a Tor exit node from his workstation. Fast forward a few weeks, and his advisor sat him down and, with a really serious tone, asked if there's anything he wanted to talk about with respect to his usage of the lab computers. Apparently some of the shit the Tor exit nodes were accessing made some waves in the department. (Bearing in mind that BYU is a very religiously conservative institution.) He somehow survived that incident, but he went out into the Real World (there's a pun here -- you should look up the whole Julie Stoffer debacle sometime) not long after of his own accord.
Then there were the students who abused the lab laser printers to print wedding invitations. All the fucking time. IIRC, it was only 10 cents a page, so it was a steal to print really nice-looking stuff at the time. Even better were the students who fed not-safe-for-laser-printer shit into the them that would melt and gunk up the insides.
Some assholes would often lock the screen rather than log out in order to "reserve" an HP-UX workstation for themselves. That got annoying when things were busy. I'd do a hard reboot whenever I ran across an unoccupied locked workstation. Apparently there were some grad students whose work that they were distributing across several nodes as background jobs would get fucked when the workstations were hard-rebooted. Personally I think that should have been a hard lesson in a "cattle, not pets" approach to distributed systems. Especially when there is effectively no physical security for the compute nodes.
There are also UUG stories. One of my favorite is when the UUG was handing out "Software for Starving Students" CDs full of OSS software in the student quad. They ended up getting reported to the "authorities" for distributing software for free.
Alright, did I tell my college sysadmin story already? This is the perfect place to drop it.
1990, freshman in college, Pascal class on AT&T Unix SVR3 3B2 cluster named "earth", "wind", and "fire". We'd just learned our way around "vi" and how to "uvapc" our Pascal source into a.out.
I discovered anonymous ftp, and "make", and I quickly rose to become the gaming king of Pascal class. I had ularn, nethack, megs and megs of games crammed in my no-quota $HOME, and I'd opened permissions for everyone else to access and play them. I often chit-chatted with a classmate or two over "write" or "ytalk".
Not content to merely play games, I became mischievous with the system and its inner workings. I created a .profile and a .plan, the latter of which used VT100 cursor escape sequences to self-modify the screen, such as changing my $HOME to "/" and I also made a boastful comment about having root access.
It was all in good fun, and then came the day that I discovered /etc/passwd and I attempted to "su" to every single system account I found listed. I mean some of their passwords were just "*" so they must've been wide open!!1
I soon received ominous, chilling email from the unseen sysadmin of the whole cluster. He described to me everything I'd done up to this point, and he informed me that saying I have root access is like telling airport officials that I have a bomb. That point definitely drove it home to me as a young and dumb hacker.
So, for the rest of my short college career, while I did some silly "extra-curricular" things with my own compute resources, I was careful to not try and break system security, or even say that I had, for fear of the wrath of the unseen sysadmin.
> AT&T Unix SVR3 3B2 cluster named "earth", "wind", and "fire".
Not related to sudo, but this brought back a memory of the cluster I had access to during my college internship. 6 computers, I don't remember what kind or vendor. Named after the starter Pokemon for generations 1 & 2. They were in the rear of the room behind a cage I did not have a key for.
One day a sysadmin came into the room asking "Uhhh... I'm looking for a... totodile?" The way he pronounced totodile made it clear he had no idea what a pokemon was.
He had to remove it and replace something, didn't really give us any details. A few days later he brought the server back and hooked it back up to the cluster. The very first thing we did was rename it to Croconaw. (The evolved form of Totodile).
They got lucky. There have been many people who even tried to responsibly report a bug, and were treated as if they were misusing the resource.
This is not just an education thing. Remember recently when there was a St. Louis reporter who found a glaring privacy violation in a Missouri state website (in that the website for whatever reason included people's SSN in the clear, but commented out. That reporter was initially treated as if they'd hacked the website and the governor of Missouri publicly spoke and said as much. Fortunately they weren't prosecuted, but even after prosecutors declined to do so, the governor still publicly called the reporter a "hacker".
Completely lost on me “babying kids and not showing them that actions can have consequences” is fetishised as soon as computers are involved. I guess because we all grew up doing this stuff.
As an adult that writes software used by a lot of students in a classroom environment, I am glad to see that the spirit it still alive whenever I have a Sentry error come through indicating quite clearly that someone is trying to cheat by dicking around in dev tools. However I’m also certainly going to make the troublemakers shit their pants with a strongly worded console.log().
During college in the mid 2000s I discovered that the network share with all corporate data was accessible (read only) to everyone.
The only way it was not immediately obvious was because only sub folders were assigned a drive letter, and the network share was hidden in the UI. I found a way around that in the Windows open dialog and then was able to trigger Explorer to the top level directory.
The share also contained private data of applicants (names, addresses, date of birth, education history) which was most concerning to us.
With some friends we wrote a document showing what we found (not explaining how to do it) and posted it to an internal message board. We also sent copies via email to our IT teacher, sysadmin and the principle. Shortly after the sysadmin invited us for a chat and basically told us not to do that again.
A couple of hours later we were invited to the principles office. The principle was away at the time, but the vice principle - who wanted to make a name for himself - immediately suspended us all and said he'd discuss it with the principle but said most likely we would be expelled, and they may need to involve the police.
Our main concern in the post we made was that personal data was effectively publically accessible (to anyone who connects to ethernet - you didn't even need to log in). Even before GDPR, our country had very strong data protection laws which this would have breached.
A few days later a parent sent a letter to the principle, effectively restating what we said, with added threats of reporting them for violating data protection of minors. Strangely after that the issue was dropped and we were allowed back...
Which goes to show us this computer thing is a learning experience for schools as well. We've come a long way since, and with things like ML we get the same experience.
My similar story: I wrote a script that tries all the words from a spellchecker I found as passwords for each user (a really naive dictionary attack). The angry admin did came as apparently each wrong attempt generated a beep on some station in their room (these were dos times iirc and the admins were just high school kids).
I, of course, did not have root access or any access that I shouldn't have had.
/etc/passwd indeed stored the hashes in SVR3, and there was no such thing as /etc/shadow. I was naive enough not to understand hashes, and so I figured that those jumbled letters in the file had to be the actual passwords, and if "*" was in an entry then "*" was, of course, the password! Why didn't it work?!!?
If you read the source of ‘cat’ and ‘more’ you’ll see that if they are reading /etc/passwd they replace the passwords of system users with ‘*’, unless you are uid 0.
When ‘less’ was created, there was a bug where when you scrolled upwards the passwords would be revealed, so it was decided that the passwords should be replaced with actual asterisks and stored in individual files per-user.
For security, these files were given access rights only for the owning user, and immediately deleted, with an encoded copy of their inode number being stored in /etc/shadow.
Fun fact: forced password changes were initially introduced when disks were getting full and deleted inodes of user password files were due to be overwritten. “For security reasons” was correct but misinterpreted.
> If you read the source of ‘cat’ and ‘more’ you’ll see that if they are reading /etc/passwd they replace the passwords of system users with ‘*’, unless you are uid 0.
That sounds so wrong, anything from a user-written program, `ed`, etc to a symlink/hardlink could read the password.
Sounds wrong because it is wrong, pure unadulterated intentional B.S.; don't know why the commenter decided to yank our chains like this.
I believe there is a meme in chat rooms where trolls get unsuspecting users to reveal their passwords by convincing them that the chat replaces it with "***" and so forth. Perhaps the GP is riffing on this.
Back in the day, not only did /etc/passwd contain (unsalted) hashed passwords, but many publicly accessible hosts were configured to allow anonymous FTP and let you browse the entire fileystem. I would never do this myself, naturally, but people collected those things and run crack on for days to get passwords for accounts.
For those wondering where the reports go, under systemd-based linux distributions ideally you can get them with this:
sudo journalctl /bin/sudo
Historically speaking however the sysadmin with access to the 'mail' command would be able to run that and see mail delivered to root@localhost for these reports. I think at least OpenBSD still does things this way [1], but they moved away from sudo YEARS ago now [2]
Yeah, I kind of lament them removing this warning if I'm going to be honest. It feels like something such as that should be more common best practice.
Of course decent log collection/monitoring should also be able to catch authlog stuff and alert accordingly and I'm sure most organizations rely on solutions like that instead of letting things get lost in email
This is a pretty short diff and it clearly does NOT do that, unless you're saying they went back later in another commit to add this. They removed the message in all situations. The string "This incident will be reported" has been removed from the source code; it could not possibly print that message now.
Is there more to the change than the linked commit? Because if not, looking at the code change I don't see how you could possibly be correct. There is no additional logic/branching that could be checking whether sudo sends mail or not, just a string change.
I feel like that warning comes right out of the era of multi-user machines with unprivileged shell accounts. That era is largely gone. Today, someone, possibly a less knowledgeable user, runs sudo on their single user laptop that they completely own outright, and may get confused who they're being "reported" to.
But there is a renewed focus on corporate laptops to remove admin rights on windows. Not really because the user is not being trusted, but because malware has a lot more options for bypassing EDR/antimalware and persistence when it runs with admin rights.
I'm sure this will come to Linux too at some point.
I've always felt it was a very bad practice not to do it.
In a lot of companies but one they avoided it for fear of receiving emails. On that only company that did it, we made sure that mailbox was clean by actually having a look when cron scripts were crapping out or when users failed sudo repeatedly and contacted the users. It was a much better housekeeping than log on a box and see there are hundreds of unread emails but dismissing it like most do.
I think it's a fear of _sending_ emails. You could accidentally trigger a cronjob that sends a bunch of emails and gets you put on spam filters. Error reporting for cron is, of course, important; but the builtin email reporting is best used for the local machine/network. A more flexible and robust solution calls out to an API that handles transactional emails/push notifications with debouncing, escalation policies, etc.
Well, it depends! Because what you need to see more often is errors. You don't want successful notifications "spam" more often than error notifications.
I think this is mostly relevant to how confused and sometimes downright mortified it makes new users of sudo when they encounter it
In other words, don't think well-configured ansible playbooks are most people's first exposure to linux although it does sound like you're doing things right which is nice to hear
I haven't used journalctl in a while - do you mind explaining how it works with a binary path? Does it report all system logging that came from that executable, as if it were a service file?
The systemd journal logs not only raw strings and priorities (like legacy syslog), but a large number of metadata fields for each message. One of these fields is the name of the executable which generated the message. The command
While they're at it, why not update the SSH warning banner with a list of what we do and don't log on this system. As a courtesy to their adversary.
This sudo message has been the same since the dawn of time. There is literally no reason to correct it. This is the one place you don't want to be pedantic, leaking security configuration via stderr.
That message is poor UI. If you know what it means, you probably don't care about the possibility of sudo sending an email when you first typed it. If you don't know, you will be worried probably without a good reason to be so.
Nowadays it's even worse than it once was, because now the natural instinct of people is to think that the incident was reported to canonical or ibm. The opposite of how they are supposed to feel about when using free software.
I'd change it to "This attempted was logged" or something like that when that is true. Just so the user is aware that the data they are typing there may be seen by someone else. But by default, in their own systems, that message should never appear, unless they specifically configured it that way.
Reminds me of when I was younger and my mom and my brother were using a windows computer. They got the message “an illegal error has occurred” and my mom called me to ask if they had broken the law.
sometimes people also complain about xscreensaver's lock screen because it doesn't use a widget library, but the alternative lock screens can often be crashed through bugs in the widget libraries they use
When I was young I had messed with the computer and it showed an english message with the word "atom" in it. My mom not being a native speaker freaked out as if a nuclear explosion was about to take place.
I don't really think this is a security issue. If an attacker is able to try executing sudo on your system, you have much bigger problems (for example, data exfil can be done by non-sudo users in many cases, or if your system is sufficiently old there's known priviledge escalation exploits). I don't think an attacker gains much knowledge from knowing whether or not they're on the naughty list.
If the attacker can execute sudo they can probably just alias it to a sudo that sends them the password and wait. The number of users on multiuser systems who don't have sudo access is just vanishingly small. Universities perhaps. But in most companies, if they trust you with access to the machine in the first place they'll trust you with sudo access.
If you shouldn't be using sudo, then you shouldn't be listed as a sudoer on that system. If you're listed as a sudoer, then you should become familiar with what sudo does.
i'd argue in a different direction: if sudo barks a scary unknown message at me, i'd avoid using it altogether and just use su, which is the opposite of what people should be nudged to do.
Yes. Largely through torturing my system and reducing it to non-bootable state and having to read up on what symbols I mangled this time and how. Why do you ask?
Social media communities really ought to observe a "leave no trace" rule with respect to GitHub and other such spaces. This commit from February 2022 is now as of today littered with a bunch of joke comments from being linked from here and previously somewhere else earlier (based on timestamps).
I just saw an IG post from a collab between a prominently irreverent burger popup in my town, and one of the most progressive wine bars in the city. It had a security guard kicking out a rowdy woman from a bar.
The comments BLEW UP with people who had never had the burgers or been to the bar calling out the "cop culture" and the celebration of authoritarianism in the photo.
It's a joke at this point, how angry people get at things that have the barest tinge of something to be mad about.
/r/SubredditDrama has had this rule in place from the beginning and it's never been effective. It may be a community norm among the regulars, but the lurkers won't care.
You might enjoy reading ann Atlantic article titled something like “I don’t wanna see you smoking pot”. It is an opinion piece about the importance of community norms.
> I received a huge amount of pushback for my remark (in addition to quite a lot of agreement), much of it premised on the idea that any social response to public weed smell would inevitably result in the warehousing of Black and brown bodies. In fact, I don’t want the police to put public weed-smokers in jail. I simply think New Yorkers should do a better job of policing themselves: a middle ground in which smokers of any color exercise discretion where the law employs restraint.
> Tolerance is a wonderful value in principle. And as the intolerant have long understood, it is also a value that can be easily exploited. It works best when buttressed by agreed-upon standards and a common investment in informal norms...
> The reflex to dismiss any criticism of violations against communal consideration exemplifies an evolving progressive politics, what the writer Michael Shellenberger has referred to as an ethos of “left-libertarianism.” In ways large and small, it has degraded urban spaces....
> When is the last time you’ve seen someone pounding shots of vodka on the subway? You haven’t, and for good reason. Drug possession was once a crime as well as a taboo. Now that we’ve optimized the admirable goal of ensuring that it isn’t the former, we need a redirect to preserve the latter.
That makes senses. I already wanted to comment that showing an false warning is not good. But silently sending a mail of what you tried to do is worse.
Not to comment on this particular case, but this is a more useful tactic than it seems at first. Seeing the reaction that an alarm brings can provide lots of useful information for evading future ones.
For some alarms yes. But for one where you won't even know if it activated unless you see the response, and there's little reason for anyone to care about it most of the time... it seems pretty niche.
At @dayjob, we have a mailing list for root@ mails. We actively use it for recording the output of cronjobs and like that. Several times a year i get sudo fail mails from random people on the terminal servers. A few years ago i actually compiled a list of the most prolific repeat offenders and they got a bag of marshmallows that have the form of coal nuggets right before Christmas vacation.
Reminds me of using Win9x when programs crashed (as often happened then), prompting Windows to present those "This program has performed an illegal operation" dialogs.
As a kid the only bit of that message that made any sense was "illegal operation" which made me wonder if I'd broken some law somehow.
The first computer at my home was a machine my father bought for bookkeeping for his business. I had a loose understanding of what that meant (around 8-9 y/o). I knew paying taxes was something he did.
I remember looking thru the BASIC manual and seeing “ILLEGAL...” error messages. I assumed it meant that doing whatever this was somehow violated tax laws. Made sense to me since the computer was used for bookkeeping.
I've always been amused by this, because I usually get it on single user systems (mine own) without mail. It makes me picture some shady office in a bunker in central Nevada, where undeliverable incident reports end up in dusty filing cabinets, indexed by incorrect passwords.
Thank goodness. That was a terrible message. I remember my very first experience with unix was setting up Red Hat 3.0.3[1] at work for a small internet company in like 1997 and getting that message and just not knowing what on earth to do. There was noone in my company who could help me and all I had was a unix book from my local library which didn't even cover linux (but I sort of thought it would be helpful).
Yes. More or less the first time I used Linux was on a fedora workstation at my desk at MIT. The very nice sysadmin down the hall sent me an email just a bit later saying "We see you were trying to install x program. We installed it for you." I understand that this is a very rare experience but the first time I saw that message, a helpful person was actually looking at these reports.
If I see info in logs and it could help a user (my userbase is internal), I reach out to them. I've coached a number of them through improving something on their end, even if it's not a critical change.
It still happens, a fellow student and friend of mine got this response ('installed it for you') about two years ago at Radboud University Nijmegen after entering `sudo apt install nasm`
I have a small server that some of my friends have accounts on. When they accidentally (or not!) try to use sudo (often this happens with a "curl | sh" thing) I like to be informed.
HN puzzles me with these downvotes. I have not a single story to share about sudo reporting the incidents and that being useful and I've managed *NIX systems for 2 decades now. Anyway, looks like there's some people out there there feel very strong about this.
Way back when my Dad worked from home, and had what I think was a Macintosh Classic II provided by his employer. I’d occasionally be allowed to play the games on it, mostly the pair matching one, which on one occasion crashed. Back then the crash dialog featured an icon of a bomb with the fuse lit, which caused me to panic thinking I’d caused the computer to blow up. Thankfully I hadn’t, and I believe that computer is still in his attic somewhere.
I got my first computer when I was about 6. It would boot to BASIC if there wasn't a floppy disk inserted. I typed something random and got back "SYNTAX ERROR". I wasn't old enough to know what either sin or taxes were, but my impression was they were both real bad.
A friend of mine ran a multi-line BBS out of his home when he lived with his parents.
One day he came home and his parents sat him down to discuss the "illegal activities" he was up to with the computers. He was sweating bullets about the secret warez section of the BBS until eventually he figured out that it was due to an illegal operation crash message!
(In that case it was probably desqview rather than windows)
When I was in uni, the computer science school actually did occasionally check these reports. Specifically, a guy named Chris checked them. Some friends of mine apparently used this to send him messages.
Similarly, at a place I used to work, messages such as "sudo echo 'Hey John, please would you chmod -R a+r on /storage/data/filename.txt, thanks!'" were used.
This usually resulted in irate "Stop that! You have to submit a ticket!" emails.
Boy, I made so many memes around sudo. I can't believe they removed it. I mean, sudo does log messages in /var/log/secure or /var/log/auth.log on Linux when something fails or is executed successfully, depending on security policies. The default on most distro is to log messages.
I remember the first time to have this message was at my first time using CERN lxplus during my undergrad. I was worried that people will think I am stupid to try "sudo apt-get" there. It was a mistake as I had several terminal sessions and forgot which one was the local.
Anyway fast forward today. I know the answer to the question to whom usually this notification gets sent. They forward it via SMTP server to the person on computing shift (at least for some of the experiments) based on the experiment this person (who tried sudo) account belongs too. probably also some IT email.
Anyway it is stressful for new and young people. but honestly I never read them. I have email rule to put them inside specific folder I don't usually open.
The first time I saw this message I was on my own danged system and I was still momentarily alarmed, hahaha. Common sense asserted itself pretty quickly of course.
How come there are seemingly zero tests for what’s essentially critical infrastructure?
How do you make sure things keep working? How do you prevent regressions as team members change and tribal knowledge and intuition is lost? How do you ensure all future humans working on the project can make meaningful changes with confidence?
Short answer: you don't, you brute force testing with your user base and you get lucky until you don't, plus you don't care because you're too entrenched.
That's how 99% of these old timey tools work (coreutils, SSH, SSL, etc). They're getting better but you can definitely feel that they're managed by old hackers that predate CI/CD.
I teach an entry level CS course at the University and my students got scared a lot when they saw that message. It was funny until I noted that they were really worried :( .
It's a low-effort addition to the dialogue, but it is a legitimate communication of a viewpoint. Who gets to draw the line of which comments should be nuked? (My view, the repo owner should (and maybe already has that power))
And my question to the github management is why can't any registered user report any low effort useless or offensive comment to the moderators, whoever they may be, like almost every other online discussion group outside of 4chan?
It's a call of duty meme, at some point your character is at a funeral and F is the action button and there is a prompt on the casket "press F to pay respects"
Strong agree on that. One person doing so was possibly amusing, everyone else jumping on the wagon is just irritating noise, and I’m not even responsible for trying to sift through that for legitimate feedback.
I disagree that it's a joke, because they're absolutely nothing funny or clever or original about it, but you're right that the point is to jump on a bandwagon, and it's intentionally ironically disrespectful of everyone's time and attention, which is also the point. It's really just a spammy childish 4chan troll.
All Due Respect: Press F for Farce.
Recently, Call of Duty: Advanced Warfare became roundly mocked when images showed a funeral event where the player is asked to “Press [F] to Pay Respects.”
>On the other hand, Call of Duty forces the player to Pay Respects for the game to proceed. It’s a mission objective just like any other, complete with an interactive reticle floating above the coffin. Furthermore, it’s embarrassing to ask the player to take this action explicitly. This is a military funeral! What else would you do, blow a raspberry? It’s no wonder players feel insulted.
>Ludonarrative dissonance is the conflict between a video game's narrative told through the story and the narrative told through the gameplay. Ludonarrative, a compound of ludology and narrative, refers to the intersection in a video game of ludic elements (gameplay) and narrative elements. The term was coined by game designer Clint Hocking in 2007 in a blog post.
I used to mix up terminal windows, and on some occasions tried to call a sudo command on university clusters. But I always followed it up with a sudo echo „sorry wrong terminal“.
Can't be done. That program is in the fossil record; change the error message and you're going to break a thousand unknown workflows that are relying on detecting that string (because string detection is the only solution they have to get nuanced information on the nature of the error).
ETA: Oh wait it was actually committed? Color me surprised.
The "this incident will be reported" message always struck me as having the same vibe as the "provided by the management for your protection" labels they have on toilet seat covers.
So, we're posting commits from almost 2 years ago as if they just happened today? Half of the comments in here can't tell it's an ancient commit; some people say celebrating saying "Glad they're finally doing this." What?
Bit ridiculous to see all the pointless spam/graffiti in the comments on that commit now.
Just change it to "This incident has been logged to /PATH." and that should be fine, right? Or, if you're really concerned about not exposing system log paths just mention it's been logged.
...only true of course if you forget that user != user agent.
Just because jschmoe seems to get his password wrong 95% of the time doesn't mean that I don't find the 9500 times he flubbed a sudo command valuable signal that something may be up. Especially if he can only recall ever using sudo himself once in a blue moon.
There is the user in the context of the system, then there is the ultimate person interfacing with and feeding the system input and output.
Hell, sudo itself is the perfect illustration of why an operator would want such a log.
Sorry, I miswrote. The actual issue is not that the user hasn't typed a password right, but that the user is not in the sudoers file and trying to run a sudo command.
Doing that just once is reported with an e-mail to root. (Would you believe it?) People have been complaining about this for years. It's a pretty poor feature.
If the intent is to remind root that some users are missing sudo access who ought ot have sudo access, the phrasing is all wrong: "this incident will be reported" is disciplinary language, like the user has done something wrong.
Likely they are just copying and pasting something from a web search (or got from an AI chat, nowadays).
The entirely separate su program generates no e-mails from people guessing the password wrong. You can grep your auth.log for that, if you care.
I just tried su with one bad password attempt on a Debian box. The program quit immediately and logged this:
Apr 30 2023 15:37:21 localhost su[22401]: FAILED su for root by kaz
Apr 30 2023 15:37:21 localhost su[22401]: - /dev/pts/6 kaz:root
that is the real message to root: the log. Don't bug people with e-mails.
The correct requirement of a failed sudo would be to emit a message conveying this meaning: "Sudo didn't execute your command because your account is not listed in the sudoers file. If you think you should be, contact your administrator." It should not be contacting the administrator for you.
Why, yes. Imagine you are in flow, and you want to show a file to nginx, but you can't. Better give root (and user) rights to nginx when you set up your system.
Very few computers running nginx have human user accounts with more than dotfiles in the home directory. Meanwhile desktops run everything on the same account because defining usable security policies between users is basically impossible.
Sure, in production. I don’t think that’s generally true though. It’s pretty common for developers to run an http server for test purposes. But anyway, that was just an example. I could have said cups.
> Whether or not sudo sends email is now configurable, so the warning may not be accurate. It is also confusing to the user since they will not know who the
incident is being reported to.
We were trying sudo and failed with enough silly passwords that we got the "this incident will be reported" message. I confidently told my officemate that these messages were never saved and recorded.
A few moments later, from our open office door (which I assume meant all our conversation was able to be overheard), our IT lady from down the hall came in and said to me "Download the internet, really?"
Because yes, I did type, while not saying I was doing so, "sudo DOWNLOAD THE INTERNET" into the terminal while goofing.
Funny story but I did feel a bit embarrassed at the time.