Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

241–250 of 302 posts

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

#241

Post by throwaway744678 »

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.

Ha, ha! Same here... The classical joke here was to send an xkill command: next mouse click will terminate whatever window was under the cursor.

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

#242

Post by tokamak-teapot »

NoZebra120vClip wrote: post #195
judge2020 wrote: post #189

Earlier quoted context omitted.

Nowadays /etc/passwd is world-readable and passwords are in /etc/shadow but perhaps /etc/passwd used to store the hashed passwords as well.

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.

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

#243

Post by hiepph »

cobbal wrote: post #60
DonHopkins wrote: post #16

Why can't I report all those idiots posting the letter "F" in github comments? ;)

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

If you keep tolerating BS then the BS will keep coming. That's why quality subs need moderators in the first place.

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

#244

Post by kaba0 »

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

I think it was just a joke from parent, not a legitimate question.

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

#245

Post by sph »

blueflow wrote: post #79

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.

Sounds like a fun workplace!

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

#246

Post by knorker »

mingus88 wrote: post #165
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.

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.

I once talked to a somewhat famous hacker by logging in to an account he set up via SSH that spawned 'talk' as the shell.

He didn't trust IRC and other chat systems.

Is the end he got caught anyway due to sloppy opsec. Like many other hackers.

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

#247

Post by kaba0 »

alexb_ wrote: post #113
kragen wrote: post #68

Earlier quoted context omitted.

something like 99% of computers with sudo installed are single-user machines where the only effect of the warning is to scare people and it's only been the same since people started to switch to sudo in the late 90s; su never printed such a warning

>the only effect of the warning is to scare people Good. If you're not familiar with what sudo does, then you shouldn't be using it in the first place.

Are you familiar with every part of the stack you are working on, down to the hardware?

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

#248

Post by psychphysic »

DonHopkins wrote: post #222
tryauuum wrote: post #152

Earlier quoted context omitted.

also wall(1)

Then there was Jordan Hubbard's infamous "rwall incident" of March 31, 1987. It was waaaay more than just reported to the local sysadmin, and almost got UCB kicked off the ARPANET. https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident https://news.ycombinator.com/item?id=31822138 Jordan Hubbard wrote: "One of the people who received my message was Dennis Perry, the Inspector General of the ARPAnet (in the Penta…

So many acronyms

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

#249

Post by amichal »

DonHopkins wrote: post #214
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.

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 was called zyphermail but the interent seems to have no memory of this.

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

#250

Post by MayeulC »

tokamak-teapot wrote: post #242
NoZebra120vClip wrote: post #195

Earlier quoted context omitted.

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

Post reply on HN