8 ms·
This article could have been published 30 years ago. In professional unix admin circles this was already well known back them. Although I could be misreading it
by fooblat 3y ago
This article could have been published 30 years ago. In professional unix admin circles this was already well known back them. Although I could be misreading it as the article is not very clear. I think this are the points it is trying to make:
1. Once upon a time you could rely on the passwd file and shell behavior as an effective means of authentication and access control.
2. It has been a very long time since that was an effective approach, for a variety of reasons, and you should not do this on modern production systems.
- deleted 3y ago[deleted]
- Attummm 3y agoWould be possible to share those reasons?
- fanf2 3y agoSeveral are outlined in TFA
- no_time 3y agoTangent, I can't find what "TFA" stands for. My gut tells me it's "The Fucking Article". Am I correct?
- mannykannot 3y agoAs I said to my mother-in-law, the 'F' is silent.
- dotancohen 3y agoWhen Gwen Shotwell was asked about the acronym BFR on international television, she replied "Big Falcon Rocket". Lovely response, quite dependent on context!
- pxc 3y agoThis is like how I use 'ofc' to abbreviate 'of course'. Once upon a time the 'f' may have stood for something, but I never use it that way. For me, 'the F is silent'.
- qazxcvbnm 3y agoI pretend its The Forementioned Article
- codetrotter 3y agoI like to read it as The Featured Article
- worble 3y agoYes
- InvaderFizz 3y agoYes. TFA = The Fucking Article. Much like: RTFM = Read The Fucking Manual.
- NavinF 3y agoYes, but in polite company you can pretend it means "The Freaking Article"
- BLKNSLVR 3y agoIn polite company you say "The article" or "read the manual" and patiently await your reward, which is their asking "what does the 'F' stand for?", to which you reply only with a condescending look and raised eyebrow(s). That look of realisation is precious. I've manufactured this experience once or twice, and it's wonderful.
- tremon 3y agoFine instead of Freaking is much nicer.
- klibertp 3y agoI think "Friendly" was/is popular explanation where devs tried to translate their subculture into something generally digestible.
- evilduck 3y agoDigestible maybe, but swapping "friendly" in for "fucking" changes the tone and intent of someone's statement. At least "freaking" expresses similar, if muted, exclamation. A recipient who is being not-so-subtly reproached with an F-bomb acronym might misunderstand what is being implied.
- hinkley 3y agoBut when the person asking was management, and asking for the tenth time, there was a decided advantage to changing the tone. All of that is now wrapped up in the initialism.
- dotancohen 3y agoOr the fine article.
- edgyquant 3y agoI really hate this acronym and this comment is no different from saying “read the article” which is against the guidelines here
- codetrotter 3y ago> saying “read the article” which is against the guidelines here The guidelines say that you should not accuse someone of not having read the article. However, as the guidelines say it is fine to point out that something is mentioned in the article. There is a subtle difference. From the guidelines: > Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that". Parent comment was in line with the guidelines IMO. And as for “TFA” as an acronym I like to read it as meaning “The Featured Article”. Then it seems nice and friendly.
- taneq 3y agoI'd assume any code in a non-memorysafe language that parses any freeform data entered by the user is a potentially exploitable security vulnerability, so an interactive shell is a huge surface area for attacks?
- dsr_ 3y agoYes, but irrelevant here. Basically any shell access means you've changed from preventing remote code execution to preventing privilege escalation, which is much harder.
- hinkley 3y agoWhich is why sudo has its own editor. If you fuck up the sudo file while saving it, you might no longer be able to log in to fix it. Before I knew about sudoedit I would open two shells as root, edit the file, then use a third window to make sure I could still sudo. With two windows I could accidentally close the subshell in one without locking myself out. Think if it like linemen, who use two tethers for climbing structures. They are never detached from the safety lines.
- neuromanser 3y agosudo visudo
- crabbone 3y agoHere are some: * Doesn't scale. Having passwords in a plain text file is not a scalable solution for users directory. Can probably go up to a hundred users, but not much more. * In computer clusters you want user identity to "stick" to the user when they use multiple machines, containers etc. That's why you have LDAP... but it doesn't help all that much because user id is encoded into the file system (huge mistake...) which makes it very difficult to contain users to things they should control. If your only mechanism was the /etc/passwd, it would mean you'd have to constantly synchronize this file across all those machines and containers you have.
- hiAndrewQuinn 3y agoTo anyone reading this and thinking "yeah dummy, of course it doesn't scale because you're not supposed to store passwords in plain text in the first place" I'll direct you to Chapter 7ish of The Linux Programming Interface. If you look in your /etc/passwd right now, you'll almost certainly see a single "x" where the (EDIT: no, it was still encrypted!) password originally was - nowadays that single "x" is an instruction to go look in /etc/shadow instead, for the salted hash of the password you're trying to check. I think this minimizes the number of users who need read permissions to /etc/shadow, and the amount of time they need it for. This has been your seemingly useless bit of Linux trivia for today. :)
- dsr_ 3y agoplaintext vs plain text unencrypted vs unstructured Of course, unstructured is also incorrect; the passwd and shadow files have structured records, one per line.
- photochemsyn 3y agoAsk the chatbot: 1. system: in the context of setting up secure remote access to a Unix-like system, discuss whether relying on the passwd file and shell behavior as an effective means of authentication and access control is a good approach. What are some reasons this is not (or is) an effective approach, which should not (or should) be used on modern production systems. user: system administrator on a Unix-based network. assistant: technically, there are several reasons... 2. If you have a collection of Unix systems, can you reasonably do a certain amount of access control to your overall environment by forcing different logins to have specific administrative shells?
- eviks 3y agoBut when was it ever effective if 30 years ago it was already well known?
- pmontra 3y agoIt was effective for a ftp server accessing public directories in the home of users. I can't remember the details but you would use the username and password of the user to exchange files with and get into that directory. All transmitted as cleartext, of course. 30+ years ago we already had services (daemons!) with their own user id, to keep them isolated from root and the human users. This post is as news as the invention of hot water.
- j16sdiz 3y ago> It was effective for a ftp server accessing public directories in the home of users. I can't remember the details ... Most ftpd need a shell whitelisted in /etc/shells . In macOS, /etc/shells begin with this comment: # List of acceptable shells for chpass(1). # Ftpd will not allow users to connect who are not using # one of these shells.
- tannhaeuser 3y agoLast time it might've been effective was probably in old-school Unix time sharing with users connected via tty's rather than TCP/IP. Already early SQL databases, with the possible exception of Informix SE, had a client/server process model where the server process had full access to all data files and would at best authenticate sessions but not individual accesses against /etc/passwd such as via Oracle's pipe/bequeather connector but more commonly would assume fixed global roles and handle auth on the app side. As soon as IP and "services" were introduced, /etc/passwd stopped being effective, as pointed out by bluetomcat [1]. Actually, even gaining shell access is considered game over from a security PoV, due to multiple privilege escalations. [1]: https://news.ycombinator.com/item?id=37462806 https://news.ycombinator.com/item?id=37462806
- tremon 3y agoEven 30 years ago, the core argument would have been nonsensical. 1. They introduce their argument as if it is solely about shell access (the conclusion also only mentions "login access control"), but then the first example/statement they make is about non-shell access (Samba, IMAP, Apache). 2. The second argument conflates authentication and authorization, and concludes that to implement shell authorization properly, your only choice is to provide multiple authentication systems. Zero effort is spent on explaining why existing/historic shell authorization systems (such as simple DAC groups or rbash) are inadequate, and it's not clear to me what threat model they are using to arrive at their conclusion. edit: rethinking this, I think TFA is just lacking a clear problem statement. They seem to be talking specifically about non-shell services that (ab)use the user's shell field in /etc/passwd as authorization information, and then complaining that many services did not follow suit.
- hinkley 3y agoFew contractions foment confusion as much as “auth”. Don’t do it.
- PH95VuimJjqBqy 3y agothe only exception is if you mean both, but even that's confusing if the context isn't clear. spell them out or use authn/authz.
- AceJohnny2 3y agoauthn vs authz: Authentication vs Authorization authn/authentication: user proves who they are, with username/password or otherwise authz/authorization: based on who the user is, system determines what they are allowed to do, via group membership or otherwise
- AndrewDavis 3y agoauthz may be confusing to non USA English speakers. I wouldn't make the connection without it spelled out to me. Unfortunately I don't have a better suggestion because auths as short for authorisation is probably worse.
- wang_li 3y agoI think the point being made is that the fact that a user has rksh as their shell means nothing to samba, ftp, some features of ssh, httpd, cron, and etc. Fundamentally unix has pretty simple permissions, you're either root or you're not. The existence of a user account on a system is often enough to enable SMB and SSH access even if the only purpose of the account is to own files and an application process and is never intended to have interactive logins or to transfer data to and from the server.
- nightpool 3y ago> I think the point being made is that the fact that a user has rksh as their shell means nothing to samba, ftp, some features of ssh, httpd, cron, and etc Which has been true for...... 30 years? If not longer?
- 1vuio0pswjnm7 3y agoThis blog of generally gibberish hits the HN front page with an astounding frequency. IMHO, there are many interesting blogs on "system administration" topics that are submitted to HN every week that never reach the front page while there are a handful of familiar, low-quality ones that routinely appear on page one.
- itsanaccount 3y agoMuch of tech is a theatre, a jobs program that keeps people employed in a middle class salary so long as they diligently pretend to be engineers. This theatre serves as a prop for a higher level theatre in our virtual economy for investors and their game of financialization. Its expected that as tech grows in number of workers clutching to that middle-class life-raft that the baseline of knowledge discussed in tech spheres (like this site) will sink lower.