is there a future for user accounting (getpw* replacement)
Igor Mozolevsky
igor at hybrid-lab.co.uk
Mon Feb 17 13:22:01 UTC 2020
On Mon, 17 Feb 2020 at 12:56, Anthony Pankov wrote:
<snip>
> > I think it's dangerous to conflate *application* users with *system*
> > users, why would you want to do that in the first place?
>
> That is the question!
>
> First of all, I think there was no technical opportunity to conflate
> applications and system users at least because uid_t is 65535 max and
> lack of custom user properties.
>
> I can note some Cons for splitting *application* and *system* users:
>
> - users of one application is not a users of another application by
> design. Applications is hard to integrate (yes, there is ldap but...);
... and SASL, and PAM (if you really have to)... and Federation (if
you really-really have to)... Why should the OS be "Application
Aware"?
> - each application has own accounting implementation which enlarge
> attack surface. Furthermore, application developers do not really want
> to implement any user accounting parts because it is far away from
> application functioning. As a result it usually implemented
> "somehow".
You speak of enlarging the attack surface, but that attack surface is
limited to the single application (or a badly designed collaboration
of several)! You do realise that if one were to have a universal
"user" awareness, then one compromised account exposes the whole
system?! The problem you describe seems to be the "lazy app
developers" who can't be bothered to do things properly and want to
palm off what is essentially the application logic down to the layer
below.
> - applications users are out of system control. There is a system
> users, application users, and daemons. It seems there is no
> chance to do the thing really right in mean of access control
> of entire system (OS +applications).
If the application users are out the system control, then application
users cannot interfere with the system, and that sounds like a very
sound design! ;-)
Best,
--
Igor M.
More information about the freebsd-hackers
mailing list