Remove “This incident will be reported.” from user warnings • Hacker News Board

Re: Remove “This incident will be reported.” from user warnings

#251

Post by dale_glass » Sun, Apr 30, 2023, 10:29 AM UTC

tryauuum wrote: post #163

teddyh wrote: post #147

Earlier quoted context omitted.

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 journalctl /bin/su can, to avoid ambiguity, also be written as journalctl _EXE=/bin/su See systemd.journal-fields(7) for more information: https://manpages.debian.org/stable/systemd/systemd.…

wow! finally something neat from journald

Finally? The thing has an amazing amount of useful features. Let's see:

* Automatic log cleanup to a desired storage size.

* Automatic compression, transparent decompression.

* Filtering by date, or boot number.

* Log shipping, ability to see interleaved logs from multiple machines.

* Microsecond precision for timestamps, multiple timestamp types and output formats.

* Output in JSON or multiple other formats, for trivial parsing.

* Cursors, for easily continuing parsing where you left off.

* Applications can log custom fields. No need to extract data from strings then.

* Captures logs that happen inside initramfs before / is mounted.

* Docker containers can log to the host's journald

It's pretty darn nice, really.

Re: Remove “This incident will be reported.” from user warnings

#252

Post by NoZebra120vClip » Sun, Apr 30, 2023, 10:42 AM UTC

MayeulC wrote: post #250

tokamak-teapot wrote: post #242

Earlier quoted context omitted.

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 wer…

> 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.

Re: Remove “This incident will be reported.” from user warnings

#253

Post by DonHopkins » Sun, Apr 30, 2023, 10:43 AM UTC

skissane wrote: post #226

noisy_boy wrote: post #194

Earlier quoted context omitted.

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).

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 cou…

>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.

https://docs.kernel.org/driver-api/tty/tty_ldisc.html

https://en.wikipedia.org/wiki/Line_discipline

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.

Re: Remove “This incident will be reported.” from user warnings

#254

Post by DonHopkins » Sun, Apr 30, 2023, 10:45 AM UTC

purpleidea wrote: post #234

DonHopkins wrote: post #220

Earlier quoted context omitted.

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"?

It does so you can pipe to commands that want a string of "press y/N" sort of things. If you want yes write `yes yes`. And one character commands are almost generally avoided. So don't name it "y".

    $ y not
    not
    not
    not
    not
    not
    not
    not
    not
    ...

Re: Remove “This incident will be reported.” from user warnings

#255

Post by DonHopkins » Sun, Apr 30, 2023, 10:47 AM UTC

amichal wrote: post #249

DonHopkins wrote: post #214

Earlier quoted context omitted.

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. Incompatible Timesharing System: https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste... Getting Started Computing at the Al Lab by Christopher C. Stacy. MASSACHUSETTS INSTITUTE OF TECHNOLOGY ARTIFICI…

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…

https://news.ycombinator.com/item?id=12951917

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:

http://everything2.com/title/Jordan+K.+Hubbard

https://news.ycombinator.com/item?id=35759965

Re: Remove “This incident will be reported.” from user warnings

#256

Post by amelius » Sun, Apr 30, 2023, 10:51 AM UTC

astrange wrote: post #112

themodelplumber wrote: post #49

Earlier quoted context omitted.

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…

> the married student housing computer labs. This is a good garden-path sentence.

Your parser needs more lookahead.

Re: Remove “This incident will be reported.” from user warnings

#257

Post by Fnoord » Sun, Apr 30, 2023, 10:53 AM UTC

fy20 wrote: post #215

notatoad wrote: post #199

Earlier quoted context omitted.

learning that if you get caught you're going to be held accountable for your actions is also part of the education. it's not as if they executed OP. telling a kid to stop screwing around is pretty reasonable.

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 contain…

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.

Re: Remove “This incident will be reported.” from user warnings

#258

Post by BrandoElFollito » Sun, Apr 30, 2023, 11:11 AM UTC

ww520 wrote: post #181

mingus88 wrote: post #165

Earlier quoted context omitted.

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)

Re: Remove “This incident will be reported.” from user warnings

#259

Post by vidarh » Sun, Apr 30, 2023, 11:16 AM UTC

mr_toad wrote: post #236

ww520 wrote: post #143

Earlier quoted context omitted.

There's the talk command on Unix. We used to do a 'who' to find out who're on the system and 'talk' to them.

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.

Re: Remove “This incident will be reported.” from user warnings

#260

Post by BrandoElFollito » Sun, Apr 30, 2023, 11:17 AM UTC

ww520 wrote: post #139

abnry wrote: post #87

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…

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 proje…

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.