←back to thread

466 points CoolCold | 3 comments | | HN request time: 0.686s | source
Show context
airocker ◴[] No.40215819[source]
I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.
replies(17): >>40215898 #>>40216049 #>>40216052 #>>40216221 #>>40216591 #>>40216746 #>>40216794 #>>40216847 #>>40217413 #>>40217462 #>>40218411 #>>40219644 #>>40219888 #>>40220264 #>>40221109 #>>40223012 #>>40225619 #
1. jongjong ◴[] No.40218411[source]
Technically not with virtual machines as the hardware is shared, though I agree, nowadays accounts and access control of the system belong to the virtualization layer below. The benefits of multiple accounts per machine are tiny and not worth the complexity for server setups.

We could significantly simplify things by getting rid of the account system. The same could be said for a lot of systems like database servers. Typically it's just one database, one user (your application server) with full access. The account system is mostly an annoyance.

For big company use cases where you want to reduce attack surface, why not spawn a second server with different credentials? Anyway big companies typically have many database servers in a cluster and the same credentials are shared by many server processes... The tendency there is literally in the opposite direction.

replies(1): >>40219152 #
2. zer00eyz ◴[] No.40219152[source]
>> Typically it's just one database, one user (your application server) with full access

This is a terrifying way to access databases.

Super user, A Modify user (just below super but cant delegate rights) for schema changes. A read/write app user... Probably a pile of read only users who, have audit trails... You might want some admins or analytics users (who have their own scheme additions).

The words security and audit trails all spring to mind.

replies(1): >>40223896 #
3. jongjong ◴[] No.40223896[source]
A simpler solution is to simply not give direct access to the database to anyone who doesn't own a large stake in the project. Expose it via a more restrictive CRUD interface with access control in the application layer.