From owner-freebsd-hackers@freebsd.org Wed Feb 19 07:58:23 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 99043252088 for ; Wed, 19 Feb 2020 07:58:23 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from smtp15.mail.ru (smtp15.mail.ru [94.100.176.133]) (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 48Mqpk1gKkz3LRc for ; Wed, 19 Feb 2020 07:58:21 +0000 (UTC) (envelope-from ap00@mail.ru) Received: by smtp15.mail.ru with esmtpa (envelope-from ) id 1j4KFO-0007nB-TK; Wed, 19 Feb 2020 10:58:19 +0300 Date: Wed, 19 Feb 2020 10:58:17 +0300 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <77695285.20200219105817@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> <419974027.20200217155651@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-7564579A: B8F34718100C35BD X-77F55803: 0A44E481635329DB0E1AA8A03B392317D32E5E4886521736714D0EA31FF8009265C502D28932F754F688BCB05C26794D11FC32B0A011826D92A1D1BB6FE7615A399CEB365C9B77261D2CD58DDFFB006F X-7FA49CB5: 0D63561A33F958A57B8CAA71B4E1D4822CA3BC1D2873107FB285788E247AC4CE8941B15DA834481FA18204E546F3947CCE135D2742255B35F6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8BF80095D1E17F4578A471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C2249505D71D783575ABE3AA81AA40904B5D9CF19DD082D7633A0BE77C518755DECA13AA81AA40904B5D98AA50765F790063734F2AC531863AAEDEC76A7562686271E8729DE7A884B61D135872C767BF85DA227C277FBC8AE2E8BDAE3FA6833AEA0C275ECD9A6C639B01B4E70A05D1297E1BBC6867C52282FAC85D9B7C4F32B44FF57285124B2A10EEC6C00306258E7E6ABB4E4A6367B16DE6309 X-D57D3AED: Y8kq8+OzVoxvgW9Op3aR8Fxwo7H2ZNxGP5qz8aO2mjTJzjHGC4ogvVuzB3zfVUBtENeZ6b5av1fnCBE34JUDkaJinJwwHx5ysVv9/YfT9uel7S36v6jwZg== X-Mailru-Sender: D8D48EF70163D79D00784CDFC8FD3107C54BE1062458E974C31F381AFF9C8BE9DD40DC63F2C6AA4550D5CF8590B94F4EC77752E0C033A69E81198BD1A48777B793AC9912533B2342AE208404248635DF X-Mras: Ok X-Rspamd-Queue-Id: 48Mqpk1gKkz3LRc X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 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)[]; RWL_MAILSPIKE_GOOD(0.00)[133.176.100.94.rep.mailspike.net : 127.0.0.18]; R_SPF_ALLOW(-0.20)[+ip4:94.100.176.0/20]; FREEMAIL_FROM(0.00)[mail.ru]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; 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]; HAS_X_PRIO_THREE(0.00)[3]; DMARC_POLICY_ALLOW(-0.50)[mail.ru,reject]; IP_SCORE(0.00)[ipnet: 94.100.176.0/20(0.06), asn: 47764(0.25), country: RU(0.01)]; RCVD_COUNT_ZERO(0.00)[0]; RCVD_IN_DNSWL_LOW(-0.10)[133.176.100.94.list.dnswl.org : 127.0.5.1]; FROM_EQ_ENVFROM(0.00)[]; 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: Wed, 19 Feb 2020 07:58:23 -0000 > On Mon, 17 Feb 2020 at 12:56, Anthony Pankov wrote: > >> > 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@mail.ru