From owner-freebsd-hackers@freebsd.org Mon Feb 17 12:56:57 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0CAC723869B for ; Mon, 17 Feb 2020 12:56:57 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from smtp36.i.mail.ru (smtp36.i.mail.ru [94.100.177.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48LkX74G5lz40q5 for ; Mon, 17 Feb 2020 12:56:55 +0000 (UTC) (envelope-from ap00@mail.ru) Received: by smtp36.i.mail.ru with esmtpa (envelope-from ) id 1j3fxE-0004Vh-Nv; Mon, 17 Feb 2020 15:56:53 +0300 Date: Mon, 17 Feb 2020 15:56:51 +0300 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <419974027.20200217155651@mail.ru> To: Igor Mozolevsky CC: FreeBSD Hackers Subject: Re: is there a future for user accounting (getpw* replacement) In-Reply-To: References: <661730512.20200217141432@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-7564579A: B8F34718100C35BD X-77F55803: 0A44E481635329DB0E1AA8A03B392317D32E5E4886521736F9FEA8B0F5145E37D2CC67C7B686A935F688BCB05C26794DCC8ABFDCEB430A40407978A7B2C0D00300829216C2FC1324AF560845B571D7DB X-7FA49CB5: 0D63561A33F958A5DAEE30CEA4DE243F7956BB04AB2375D38B9919F3CEDB30618941B15DA834481FA18204E546F3947C17119E5299B287EEF6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8B974A882099E279BDA471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C2249505D71D783575ABE3AA81AA40904B5D9CF19DD082D7633A0BE77C518755DECA13AA81AA40904B5D98AA50765F790063734F2AC531863AAEDEC76A7562686271E8729DE7A884B61D135872C767BF85DA227C277FBC8AE2E8BDAE3FA6833AEA0C275ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85D9B7C4F32B44FF57285124B2A10EEC6C00306258E7E6ABB4E4A6367B16DE6309 X-D57D3AED: Y8kq8+OzVoxvgW9Op3aR8Fxwo7H2ZNxGP5qz8aO2mjTJzjHGC4ogvVuzB3zfVUBtENeZ6b5av1fnCBE34JUDkaJinJwwHx5ysVv9/YfT9udwNEOvzTh/sA== X-Mailru-Sender: D8D48EF70163D79D00784CDFC8FD310736D973F3AB9FBED9F7A467B04588471F8D85D87526EB286750D5CF8590B94F4EC77752E0C033A69E81198BD1A48777B793AC9912533B2342AE208404248635DF X-Mras: Ok X-Rspamd-Queue-Id: 48LkX74G5lz40q5 X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.100.176.0/20]; FREEMAIL_FROM(0.00)[mail.ru]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ipnet: 94.100.176.0/20(0.06), asn: 47764(0.25), country: RU(0.01)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[mail.ru:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[96.177.100.94.list.dnswl.org : 127.0.5.0]; HAS_X_PRIO_THREE(0.00)[3]; DMARC_POLICY_ALLOW(-0.50)[mail.ru,reject]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[mail.ru]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[mail.ru.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 12:56:57 -0000 =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, Igor. =C2=FB =EF=E8=F1=E0=EB=E8 17 =F4=E5=E2=F0=E0=EB=FF 2020 =E3., 15:01:14: > On Mon, 17 Feb 2020 at 11:15, Anthony Pankov via freebsd-hackers > wrote: >> >> Greetings, >> >> I'm wondering has anybody any thoughts about user accounting >> provided at the system level? >> >> It seems that getpw* doesn't suit the needs of application services. >> All applications has some external/internal mechanism for storing and >> retrieving user properties (settings, roles etc). Furthermore they >> implement own security policy based on this mechanism. >> >> Mostly it is done via LDAP connection or internal store (as for database= ). >> >> It seems that all application developers will be more happy if OS will >> have a few functions to do the things such as: >> - list users of some type; >> - get user properties specific to application; >> - get user roles specific to application >> -? >> >> Does anybody has thoughts about what OS must provide to keep >> applications consistency and make developers happier? > 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...); - 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". - 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). - etc. --=20 =D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC, Anthony mailto:ap00@mail.ru