From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id OOkABsjl92LrZAEAbAwnHQ (envelope-from ) for ; Sat, 13 Aug 2022 19:56:24 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YCvnBcjl92KzMQEAauVa8A (envelope-from ) for ; Sat, 13 Aug 2022 19:56:24 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C345CD232 for ; Sat, 13 Aug 2022 19:56:23 +0200 (CEST) Received: from localhost ([::1]:40662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMvN1-0000lL-1V for larch@yhetil.org; Sat, 13 Aug 2022 13:56:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44824) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMvLj-0007u8-Af for guix-patches@gnu.org; Sat, 13 Aug 2022 13:55:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45310) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oMvLi-0000qh-IK for guix-patches@gnu.org; Sat, 13 Aug 2022 13:55:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oMvLi-0007pB-E8 for guix-patches@gnu.org; Sat, 13 Aug 2022 13:55:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#56690] [PATCH] gnu: seatd-service-type: Should use seat group. Resent-From: muradm Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 13 Aug 2022 17:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56690 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= , 56690@debbugs.gnu.org Received: via spool by 56690-submit@debbugs.gnu.org id=B56690.166041326730011 (code B ref 56690); Sat, 13 Aug 2022 17:55:02 +0000 Received: (at 56690) by debbugs.gnu.org; 13 Aug 2022 17:54:27 +0000 Received: from localhost ([127.0.0.1]:35054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMvL8-0007nz-Oa for submit@debbugs.gnu.org; Sat, 13 Aug 2022 13:54:27 -0400 Received: from nomad-cl1.staging.muradm.net ([139.162.159.157]:51284 helo=nomad-cl1.muradm.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMvL6-0007nm-On for 56690@debbugs.gnu.org; Sat, 13 Aug 2022 13:54:25 -0400 Received: from localhost ([127.0.0.1]:53248) by nomad-cl1.muradm.net with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1oMvKK-0003gh-2l; Sat, 13 Aug 2022 17:53:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=muradm.net; s=mail; h=Content-Type:MIME-Version:Message-ID:In-reply-to:Date:Subject:Cc:To :From:References:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=MTwxa7zEAr9CPo0/f8ZQC/1ngbbnbD7pAYWf8Souoyc=; b=rLXl9DCEQmJhaTR1cBUr7QwF/S LCLgz93vZO81vzEqlNu5wf2JHSpj4wdFrY+Oye1Ow9eCAsIyd+HzgqOgbxVXQ2J7UCW5W05o+qwwn 6Nccor47aAvL6z3OF76QnGv6X0mjzzbPjH/A4aiiBdAT2Su/Z+VEsAEC7rxA/+VpOviak2vjYoXq0 VoxLYyTjsQOOh8OofANRSGQ1VM3wEhHm8c2Y6Gilpbw5CA31dpukdc2Mf9OB76kjWXaTbxYfRHgOu GVDnt4qXsP4AiHyhKaXKK4c5izwdwnr0ZTxvQkHnj0iN6FTZe+0eb4A8D7XtiGVnor2r2J8yauMrh maSxq9RB3CqMaOdZSMz565bHoEKxiRXARc/7CRBIo3G6yJKYHy2Rjz8yqtg7z3ap1EMnr2tnrlrgs 9nt/ZA0/3Y/VefrwQXwYPL5qMD4idrnxAgX/KrvGEnFI/rOrFkdQG6fk+SGAZMcyYqnxZ1wYZ+Kc7 xdJUueWZu/DApVpOTOENmfOV; Received: from muradm by localhost with local (Exim 4.96) (envelope-from ) id 1oMvKx-0000sk-0e; Sat, 13 Aug 2022 20:54:15 +0300 References: <20220722042745.26745-1-mail@muradm.net> <87czdddrra.fsf@gnu.org> <87les00x51.fsf@muradm.net> <87h72n24ra.fsf@muradm.net> <55a3a3bf118f364b70cbd74d214998955d81eaa9.camel@ist.tugraz.at> <87mtcezhty.fsf@muradm.net> <063eee23b1ff1b0f288d5e465aa5bac1862c9bb8.camel@ist.tugraz.at> <87y1vxxjrt.fsf@muradm.net> User-agent: mu4e 1.8.7; emacs 29.0.50 From: muradm Date: Sat, 13 Aug 2022 20:39:25 +0300 In-reply-to: Message-ID: <87mtc8112x.fsf@muradm.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1660413383; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=MTwxa7zEAr9CPo0/f8ZQC/1ngbbnbD7pAYWf8Souoyc=; b=UX1JYrVh8MvqmwvwOGp/EMA2BSKjurVNAEsCLQ92VEbglQMK1zsuH/9o433///g/cvjOfv V09fssvpPxURgWU9ljXFVGkJL8G0MJMOQZMW2brUDYiEjX8YhnGOqKrS3MuSurzMYZjS9C +yJtY4+Vgg18acfyBzjrxQ6FB/2NC8O1Ejbv4q6F1FCduCxGPHlLvviKXHMhkzyXou/O47 Ubda7RfC8PrDZhRbm0oMmhgJqIeEY+gjyTsAl6xv/gynL0I8nS4CaVS5y/ggz3zZxmrUW3 MOZNMufti7B1bJyAhGjhIwzUqR5WqFYATUsJkjPNAfY39i+bh3+9jYJGjyG8kw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1660413383; a=rsa-sha256; cv=none; b=iaq2WpX1jNF1Yc3pZKuvs33kNjwGUdN2PZ/pK4IzBzj4TASNG2PlGS2ZB975Gg6DsGn2Vw 92aBdstTWZzGSviAugxWphL5gqKPUHTksNvaRzmEyw85/ukPv/bJzhr+tgWS15O4OpAyh3 CIEWTC9oJVjtyWmm646ZQwx/CSGF3CyFi+HCaMftaOEIx46cs4ZDBv7KTiS56RGGclfwDn Rv40bkttojRBJeg7VcsLoN93r6RfodhGDN09kuBu4B9Qym5qSfaiNanEfPWw8/ZqcwCjXk M8uudTGhN5o7daLSyiN6NYUBVxcUDirOyww14pz5OjXcnOZidB31hlts3flktA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=muradm.net header.s=mail header.b=rLXl9DCE; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.06 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=muradm.net header.s=mail header.b=rLXl9DCE; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: C345CD232 X-Spam-Score: -2.06 X-Migadu-Scanner: scn0.migadu.com X-TUID: 9RkJ+PcQqthd --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Liliana Marie Prikler writes: > Am Dienstag, dem 09.08.2022 um 22:47 +0300 schrieb muradm: >> There is no such specification as login manager or what ever.=20 >> User >> is any one/thing acquiring resources via seat management. It is >> perfectly fine to run mingetty, login into bash and from=20 >> command line >> start sway that will use libseat to acquire video for instance.=20 >> Who is >> user here? >> >> There is also no display manager as it was before. Please see=20 >> my >> explanation to unmatched-paren: >> https://debbugs.gnu.org/cgi/bugreport.cgi?msg=3D46;bug=3D56690 >> What is sway in this usecase, it is not a user (like you or=20 >> me), >> it is not a display manager (as gdm, sddm etc.). It is just >> application requiring video card (not only) resource, which >> it instead of having exclusive root access, uses libseat to >> acquire it in "seat managy" way. And greetd does/should not >> care about seatd/libseat until it is not required to acquire >> resources in "seat managy" way. Instead it is a greeter which >> is totatly customizable, could be even a bash script or small >> suckless-like application or else. >> >> This is the point of seatd I suppose, to do one thing only >> without enforcing on who should do what. >> >> Thus, none of your proposals are suitable, and I can't come up >> with something better than "seat management user" or "libseat >> user". However in my opinion, the one who commits into such >> setup, should be aware of what is seatd libseat and how, why to >> interact with it. > I think you're mixing user and application here, which makes=20 > explaining > this to others difficult. For instance, GDM is both an=20 > application > (display manager) and a user launching this application.=20 > Likewise for > most other display managers. Thus, there is a 1:1 mapping=20 > between > users and applications. I don't think that I miss, instead I intend to generalize as much as possible. I suppose it is better to say, seat management can be used by anyone or anything where greeter would be an example of anything, and logged in user an example of anyone. > With seatd, from what I understand, there is no such mapping.=20 > However, > given your description, the following is unclear: > Does alice need to be in the seat group to run bash? Alice needs to be in seat group if any application and/or script is going to be using libseat for acquiring resources in "seat managy" way, in order to have access to seatd.sock. > To run sway? Since sway is aciqyuring resources using libseat in "seat managy" way, then Alice will have to be in seat group to access=20 seatd.sock. > To run sway *only if not having talked to greetd first*? greetd is unrelated here, as greetd by it self is not acquiring resources in "seat managy" way. Currently no greeter for greetd also talks via libseat to seatd _directly_. But special case of gtkgreet which requires wayland compositor, which is sway, creates indirect relation of "seat managy" resources acquisiion using libseat. This indirect relation requiring user of greeter to be a member of seat group. >> > > > > +=C2=A0 (group seatd-group (default "seat")) >> > > > > +=C2=A0 (existing-group? seatd-existing-group? (default #f)) >> > > > AFAIK this is not necessary.=C2=A0 accounts-service-type can >> > > > handle >> > > > multiple eq? groups, so as long as you're careful with=20 >> > > > what >> > > > you put >> > > > into group, you shouldn't get an error. >> > > ok field removed >> > Note =E2=80=98eq?=E2=80=99 groups here.=C2=A0 In other words, you shou= ld be able=20 >> > to >> > take a >> > group (not just a group name) for the group field, sanitize=20 >> > the >> > field >> > so that it will always be a group, and then use that group in >> > seatd- >> > accounts (see the second option mentioned in >> > <79341a82bf9cd5fc6c2227255095f3fe2927dcbe.camel@ist.tugraz.at>). >> > If >> > for instance instead of seat, you wanted the video group, you >> > would >> > have to take the one from %base-groups, rather than creating=20 >> > a >> > new one. >> Sorry, but I'm not so proficient in english as you. I can only >> speculate on what is written here. And that reference does not >> say anything to me, even duck duck go gives single result, it=20 >> is >> your message. Could you please be more specific here, and/or >> provide more useful hyperlink style references. Thanks in=20 >> advance. > I'll explain it in terms of lisp: > > (define seat1 (user-group (name "seat") (system #t)) > (define seat2 (user-group (name "seat") (system #t)) > (operating-system (groups (list seat1 seat1))) ; works, eq? > (operating-system (groups (list seat2 seat2))) ; works, eq? > (operating-system (groups (list seat1 seat2))) ; doesn't work > > For field sanitizers, see define-record-type*. I know how eq? works. I don't understand what do you want me to do with service configuration. > Cheers --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEESPY5lma9A9l5HGLP6M7O0mLOBeIFAmL35UYACgkQ6M7O0mLO BeJyKBAAxDyzpy8EXgNr8H8wYP6nCg5pvT/+KXEu3EnARDuDo1RYvU1r4X42OsTq CGMY2IcwXNOox2Z8f8lWE/ljV9FaBvFLXy9kGrOVaBYhE6PM1DWeAjHS2i4EiOru a1gZn/CPSi/6LiEah0PRIigySJSK9nky6Rt+5iveQPAy7qx9lp0hJklH2tso7/Yn Xu8Q8lxDkLFw7yixNiISBjOsU7xkT40lHU/4vY5wM0KmXj8sClRZAmRcPb32SdgX 9Vv04bQI3S98TEflYUxl84L+aGjwk4NTMmThflUHOG1/+ql9xY+7nS0J1sYIsCns Qr2F6ar9cB6QpEkH3t1cAlAX//azz7mMVhzBaBsvS1nG7L6woL558/wmYLgDmqNd dQ/r86lvd2o30qKT2bnF3sgpaWGCnEbL9m/CJfJ286kH2xlqpBQeMW9t/h3+q+UV 89cNYjDyJbpVuG+zzhRu8MeJm4+Ae1hxUyS9do4uId8WC18mvwzNo7Z6YjOOwcVA QeC7Jh7hF1Smd+TiisqaXZd6Eb7vOvO4eFCiQ3uaHP4kCoYGl6JQj5sRZroeIVMl 84Hq+lW9V2AWZ84kR+h4NW00Udtg0RM+xDuAti75/FV1tz1OuWvdT0pR+RKizsgW yHZSoDwIkG1e9MtFpJzSp2NoBdT76tiDBTYQf4l5HrTlgC1gbNE= =xhn8 -----END PGP SIGNATURE----- --=-=-=--