[vbezhenar]

suid bits are flawed and ideally should not exist. You should only be able to drop privileges. su/sudo should be replaced by ssh anotheruser@localhost (or simpler implementation with unix socket and without encryption, but the idea is the same).

[chasil]

You would not be able to change your password without suid.

I guess there are ways that sudo/doas could be adapted to implement passwd, chfn, chsh and friends, but the approach appears to have been chosen in the '70, and codified by POSIX.

How do you think these should be implemented?

[vbezhenar]

Just make a request to the service which runs under root to change password. Include necessary credentials (e.g. current password or its hash) and new password (or its hash). How this request will be authenticated is another matter, but there are plenty of ways to authenticate a request. Or may be there should be better ways if current ways are flawed.

My point that it does not have to be coded in the kernel as a dedicated mechanism to circumvent protection. Use any IPC channel to send a message to another process which already runs under root and accept those messages.

[chasil]

On this, you must understand the original "poverty of UNIX," in that it originated on a 16-bit PDP-11.

There was no room in that environment for a running service to elevate privilege, so it was implemented as a kernel system call.

This poverty meant that efficiency was required, and setuid was the most efficient mechanism.

It was a reasonable and efficient mechanism for its time, and it has successfully scaled to the realm of modern supercomputers, and remains efficient on the lowliest of embedded systems.

Maybe there was a more secure option bearing in mind of all the places that UNIX was forced to go, but I cannot think of one.