From nobody Tue Aug 20 19:23:23 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WpKBW6wTPz5SRbD for ; Tue, 20 Aug 2024 19:23:31 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WpKBW19xFz4YHJ; Tue, 20 Aug 2024 19:23:31 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1724181805; x=1724848471; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-author:resent-date:resent-from:resent-sender:resent-to: resent-cc:resent-reply-to:resent-message-id:in-reply-to:references: mime-version:content-type:content-transfer-encoding:content-disposition: content-id:content-description:message-id:mail-followup-to:openpgp: blahblahblah; bh=LlWjrmPDohkJ1yINQisr06VpI7ui9z0kmfs4GOVglHE=; b=HWX+BjijnBnKk5GfclDei8qzxhqolaVRk4PiDEJzowbdkBvsFmg8z1GbtkzqVqu783x1IOJi 5upt2NK9+jHrK1cc++KeMdePNf4UvC8PUz5LQEc3soRE4YG/za4rqk5ur1ETNO0SterARhXNOP dU5NXibnVMxrSnYvBDMW/4df3tycmIhvcHHsCa+SaaRCux3HhdRhjsip5TYtXTlQQou+4RK7Si aBsFXdl+DK9LHw1ccRBJgUg52SPeSQ/7ML0aDa8D908HCD8CyoiOzoXyu1evr1hX9G4GAgayiD dIoQKtC5Z/uvYQA65CTdGh4PhPWcn3qxytdpuD88sAcjaI4g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1724181805; x=1724848471; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-author:resent-date:resent-from:resent-sender:resent-to: resent-cc:resent-reply-to:resent-message-id:in-reply-to:references: mime-version:content-type:content-transfer-encoding:content-disposition: content-id:content-description:message-id:mail-followup-to:openpgp: blahblahblah; bh=LlWjrmPDohkJ1yINQisr06VpI7ui9z0kmfs4GOVglHE=; b=Nv5rYFKpAwLAGhzSw1h/8KEQY1mDcamZ5j/lwzffCVteyMgrBaJ7y0Ng8Uf62Pv6OQFFerYT CyLUYF2E4frwCw== Date: Tue, 20 Aug 2024 21:23:23 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Gleb Popov Cc: freebsd-current@freebsd.org Subject: Re: a zfs thank you :) Message-ID: <20240820192323.OaLjIO5I@steffen%sdaoden.eu> In-Reply-To: References: <20240819190714.mtYVCmQC@steffen%sdaoden.eu> Mail-Followup-To: Gleb Popov , freebsd-current@freebsd.org User-Agent: s-nail v14.9.25-599-g5c75a327b2 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Queue-Id: 4WpKBW19xFz4YHJ Gleb Popov wrote in : |On Tue, Aug 20, 2024 at 12:18=E2=80=AFAM Steffen Nurpmeso \ |wrote: |> Jan Bramkamp wrote in |> : |>|On 31.07.24 17:02, void wrote: ... |>|> [.] when adduser was invoked, I was given the option to |>|> encrypt the homedir. This is a great feature for my context [2]. |>|> |>|> It doesn't automount on boot but I think this is more of a feature |>|> rather than a bug. One can have a different password to the GELI \ |>|> one used |>|> to boot up the whole system. |>|> |>|> I have not tested yet whether one can have the user, once logged in, |>|> mount |>|> their homedir with doas(1). Right now, I mount the homedir like so: |>|> |>|> zfs load-key -a (prompts for password) |>|> zfs mount -a |>|> |>|> as root. ... |>|> Can anyone suggest any better ideas please? |> |>|There is the pam_zfs_key.so PAM session module that should do exactly |>|what you're looking for if your users login with a password. It should ... |> To suggest a screen locker for "warm" security. |> Ie here this is (on Linux, in /root/bin/zzz.sh upon lid close etc) ... |> for p in $(pgrep X); do ... |> act "DISPLAY=3D:$disp $SUPER -u $uid slock >/dev/null 2>&1 &" |> done ... |> Unfortunately there is no other easy way i know to lock all |> X sessions otherwise. |> |> This is the problem i have with "encrypted home directories" per |> se, i do not use that, but have several encfs directories, like, ... |> [.]all these are unmounted upon LID close etc. (Unless some |> process uses any directory within as CWD/pwd(1), then not. Force |> unmounting does not work.) |> |> Ie that is all pretty uncomfortable (it is even more complicated |> in practice), but like this data i care of a bit more is not [.] |> Anyhow. To remark that PAM sessions can easily be bypassed by any |> shell script (script /dev/null 2>&1 &), and, i looked |> at the ZFS PAM module in particular a few years ago, it did not ... |> It would be cool if the PAM implementations i know (Open and |> Linux) would consider adding a dedicated session reaper, with all |> session related modules stopping doing lots of dances, but instead |> relying on some generic PAM library support mechanism. |> Sounds a bit like a sophisticated and relevant Google Summer of |> Code or something project. | |It feels like you're reimplementing ConsoleKit. I'm not sure if it can |react to lid closing out of the box, but it manages sessions and |locks/unlocks them depending on circumstances. I .. do not know consolekit, but it does not look as if i want it: $ prt-get info consolekit|grep Dep Dependencies: dbus,gobject-introspection,linux-pam,xorg-libx11 (Funnily i do have the dependencies installed, gobject stuff for harfbuzz for mupdf, DBUS for iwd (wireless) and bluez.) No, but i am happy that noone wants to start introducing systemd into FreeBSD, i think it can do something like this. PAM sessions are broken unless anybody plays nice for sure, and with dedicated reapers that could be overcome. For my LID close things, there is software which allows paranoia, gpg-agent for example supports SIGHUP This signal flushes all cached passphrases Unfortunately i failed to upstream the same for ssh-agent, 'thus i have to workaround it (or patch forever). And unfortunately encfs does not support auto-unmount on SIGHUP, also. So it cannot be as easy as pkill -HUP ssh-agent pkill -HUP encfs ... called by root on LID close or so if one wants to increase "warm security" (i think this warm / cold terminology is from PHK). And that there is no general way that offers automatic screen locking for all X and console sessions on LID close, requiring password entry for unlocking, that is really strange. Maybe ConsoleKit can do that more easily, and portably so. (But i keep on using the simple shell script loop, as the shell script is anyway running on LID close.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)