[fooblat]

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.

[tremon]

Even 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]

Few contractions foment confusion as much as “auth”. Don’t do it.

[bigbuppo]

You're not thinking like a thought leader.

[1vuio0pswjnm7]

This 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]

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

[wang_li]

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

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

[Attummm]

Would be possible to share those reasons?

[crabbone]

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

[fanf2]

Several are outlined in TFA

[taneq]

I'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?

[photochemsyn]

Ask 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]

But when was it ever effective if 30 years ago it was already well known?

[tannhaeuser]

Last 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

[pmontra]

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