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