is there a future for user accounting (getpw* replacement)
Anthony Pankov
ap00 at mail.ru
Wed Feb 19 07:58:23 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! ;-)
I think it is greatly depends of system appliance. If we speak
about *system* as of part of IT infrastructure that provides some
technical service then I fully agree. Excess users is disadvantage
and OS survival is equal to *system* survival.
But if our deployment include applications human interact with
then *system* concept goes wider. In this case OS survival is not
equal to *system* survival. When users/orgs lost their data or facing
*system* malfunction they don't care that underlining OS did
survive and not compromised. I think that in wider *system* concept
idea to bring to OS fine tuned users accounting that will be shared between
applications have to be considered.
--
Best regards,
Anthony mailto:ap00 at mail.ru
More information about the freebsd-hackers
mailing list