From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f181.google.com (mail-dy1-f181.google.com [74.125.82.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3F15331211 for ; Fri, 13 Mar 2026 18:03:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425026; cv=none; b=J4+XSQ76oZGgA97vf3MgNVj+fuks/3sCin8tsQ7eRpmemTfpNYcAKhEZu2Awu5w4hzclixGoFl9s5xdX5obO3egOdHY2yuU0JyXUXO0S86ewcqXecrQLzlCeM3l6vDy3Q6rnkThXzTje4XqjyFzNvaoaoauCG7GyJ/bcwmXbWCk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773425026; c=relaxed/simple; bh=Vw53QYHKCbG3i2bjJKJQ7E1adE09hd57m/qLrHD7O6w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eekVJiIaHIGkRQRu2vP3s+p0F+XYaSD+3Ru7ZLZmumrn9MZK8tsA8U6V5b8XOodQal/IXcYSb+L+qhrRj+eXen/nFijFh7xQhftng+VXyu3NJGLW+5xa/SzXBfOPRJDslcGtF+2JF/igkC9e3ZxuF8nVy8BQF3jwQclwTlHbKV4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=mWdZxpOS; arc=none smtp.client-ip=74.125.82.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="mWdZxpOS" Received: by mail-dy1-f181.google.com with SMTP id 5a478bee46e88-2be9c886a0fso3241507eec.0 for ; Fri, 13 Mar 2026 11:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773425025; x=1774029825; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=PSOEv1xERLgXH2ZBdcqMBoKy0zuIxCKcPMy4xL8vk84=; b=mWdZxpOSWxtpK8upexkeRRp1Tj4uXKlnfgSalwu40eQRl4fr+6O9jFnQrIbBcG86mo tDIC6wppEDWvo8E9AZP5HYrNHFVt8w2YjNIe8PfUoYiRMoywZWsJ/FwTMOqJC+94/K92 5DCvynQKXQLr0ND9XM7bba1W5f14doEOgvV8sBpBAVdAuKUesCf/3yD7j2Gzv61sPDfc vEVzwtXltNLcpDlmacLv2guX3Avea8VgyAX3FVAqEyDQFRPUy03sUs+yKXosO0VBV6W/ 8pZ9YRB8DLri6emjsSQyS0SapiSywMli2LdgZcr+TdcPJk88pNcfc6Q3lYXdp61QS8s9 2Yzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773425025; x=1774029825; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PSOEv1xERLgXH2ZBdcqMBoKy0zuIxCKcPMy4xL8vk84=; b=Pnm/2iv/JsIe6juD84UcWy7c0FyJu0AnQPaZQUKPD7tIJ9q7kiHQVme7q1qP0Y/D0Y FzAXZHW21NVuiUwo8ygMdMugQMNmvEGiMrd6o6ZIkbtMDtU93w0L+UgaSyiAycT2xz4U gPS44/SSTPKzKAVG52uOeekaTFCCGvmhnKDN+lQ2tgXLSTpyiWA8/8qpOexv9XJfU6Xg 2hqzynhJ9rNfWgQRyDc+C9FgR0dMBn3CSPUsaplS7FZfVnA6b31Xp63oa1yQ/l4SkBeG l6lkxTdSkeRlktxGqg8HHW0cz7PSOg2NAtxzaKn9gbkxfkCyBybAduqH0DgXR525x5Kw lq3g== X-Gm-Message-State: AOJu0YyY/j2FObDj7rLTgHRlAaPfJ34xd5+KgDPciLxBtxZ7Gpty2v2D Kpj8u8kT2BJr6VK4NA1KxPS/2M/I7nhiqEaFCn7tt7UWwqXp6uv8MkkXwQNrQO1RZDk= X-Gm-Gg: ATEYQzwlog5744IpihgNmxk2czn9/tpItocgkHOY/hp2HKqfnbvJbWFr8hb59es+KDd QhLbkxuhftEWyFSPb85TS0FMR8NcuRrdllN3JIA2AXCHjm7q+FcsvzNC1s+HYH7D251+Rvx1Zjo 7ZpTqVZKBI5j151Zm+DNJzfKdS1A0M/0zhvMG8lgX+D+b/75EXba72CK/LDSOUIPBXNcQN27+mb zum96tOEYiprnvzA1opafHdb+mOTCOgdi19kEb6Zgeae1caPgl+jd5Ha7aXgHYz2ZNg+RpNh8dM YZYTq+YOHsHuy3PVB4vROg7zM3+lOmSldk3aQoyfkbeIykqebZmLCNt7O0P4sKvX7FARyAc3n4Z ElsA7w1R+cfU0AZHEI1SNYjFfcZDgJixYGMfrSvXqFp9nSNI+dEuHnuAZKuz1TOlIxzRGbCkx6x 3DNhTdJxuZs9/5yg36ucRbkMgeial/Yv4FDAxQ8PGfAa6lrudcxMvaFVdV5IrPEFBk1he6zMLb8 HSl3wD2vEriQ2cR7vFbSNimQae85K8= X-Received: by 2002:a05:7300:72c9:b0:2be:8216:57d2 with SMTP id 5a478bee46e88-2bea5442cd0mr2235815eec.9.1773425024417; Fri, 13 Mar 2026 11:03:44 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:49c8:a562:e69:d236:fd56? ([2804:1b3:a7c0:49c8:a562:e69:d236:fd56]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2beab526f9asm4197038eec.19.2026.03.13.11.03.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Mar 2026 11:03:44 -0700 (PDT) Message-ID: <33904ff8-c018-4464-8876-ec8035e14b05@linaro.org> Date: Fri, 13 Mar 2026 15:03:39 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] Modernizing Linux authentication logs (lastlog, btmp, utmp, wtmp) with SQLite To: Roman Bakshansky , linux-api@vger.kernel.org, Thorsten Kukuk Cc: linux-kernel@vger.kernel.org, audit@vger.kernel.org, libc-alpha@sourceware.org References: <660c10e6-f8b5-46e2-a424-e3e052992b3a@gmail.com> <2d5de14a-17d2-4d08-992e-cbc5d430e231@linaro.org> <948e83d4-4a34-41d5-a394-6c4ec17bc534@gmail.com> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <948e83d4-4a34-41d5-a394-6c4ec17bc534@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 13/03/26 14:48, Roman Bakshansky wrote: > On 3/13/26 4:59 PM, Adhemerval Zanella Netto wrote: >>  From the glibc standpoint my plan is just to make the accounting database >> function no-op [1] (I hopefully to get this in the next 2.44 release). >> >> And I think Thorsten Kukuk already adapted most of the usages in current >> distros [2][3] using similar strategy, along with a better systemd >> integration.  I am not sure if/when distros are incorporating his work. >> >> [1] https://patchwork.sourceware.org/project/glibc/list/?series=37271 >> [2] https://www.thkukuk.de/blog/Y2038_glibc_lastlog_64bit/ >> [3] https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/ > Thank you for the links and information. > > I have been following Thorsten Kukuk's work. I know that liblastlog2 is already integrated into util-linux and successfully solves the Y2038 problem for lastlog. I am also aware of his wtmpdb project. These are important steps in the right direction. > > My RFC proposes to go further and provide a unified solution for all four files: lastlog, btmp, utmp, wtmp. The idea is to create a set of public libraries (liblastlog2, libbtmp2, libutmp2, libwtmp2) with a consistent C interface, built on SQLite. This would provide 64-bit timestamps, indexes for fast queries, ACID transactions, and schema extensibility without breaking backward compatibility. I think you will need to check with the systemd developers whether they are willing to integrate this idea into their plans (if they haven't already). I recall that systemd is extensive in some form. My understanding is that eventually all distros, at least the ones that are systemd-based, will use the systemd-provided framework instead of relying on different libraries. >From the glibc standpoint, providing this was always problematic, and I shared Rich's view (musl creator) that the interface is insecure and legacy [1]. If I were to implement something not systemd-based, I would follow the direction that utmps used[2]: a daemon as the only authority to handle the files and all clients (utmp{x}.h} uses will just query through IPC. It means that users should not care whether how or where the database is placed (the _PATH_UTM and related macro should be handled as legacy and deprecated), and the client should only care about the record structure in the usual C form, along with a version (so no extra concepts on how the record is placed in the file). But I wouldn't put any extra effort into a different API as you did; rather, I'd check how to adapt legacy programs to work better with systemd. These interfaces are really legacy, and I think we should move away from them. [1] https://www.openwall.com/lists/musl/2012/03/04/4 [2] https://skarnet.org/software/utmps/