Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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


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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: