From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f53.google.com (mail-dl1-f53.google.com [74.125.82.53]) (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 D84ED3C2D for ; Fri, 13 Mar 2026 13:59:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773410359; cv=none; b=BO0G5Z1aVW7XAMVPWHHHZoEAq1FJHgmD55oggdfwwjOkmXhtVfKunpNBeVPpuYCNrxM1xEpkA3yBUPVyE+5OnK6+dTuAtBXOdVSRUOnwpRhB5IznmmTlwlP9NQE7quy3lPr2EX40yYLZWIwNb0vXqzF6bK7HwVps1GJLkEA2rM4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773410359; c=relaxed/simple; bh=G/2GudsY16WgckOKKpfCxUlxP4/qeV6zEYS3Nvez+uk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CM4/VcaHlpO/VGTZrKuZpExmzxOJ7JXWBrDGezy7+94A+lIEn4lV0WS0iPoMbaIjSkkgDtWVXidZbWk6wNki+B94HoA/SksL4fm6eAXpXZctCP/P3GYHDNFJp9fw6/MSJPv9m2rKzKzgi4PsyeJ1Kzk1rof3VctJoc5u2rm8FXo= 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=FhtvxNdH; arc=none smtp.client-ip=74.125.82.53 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="FhtvxNdH" Received: by mail-dl1-f53.google.com with SMTP id a92af1059eb24-128d2e3082eso1793094c88.0 for ; Fri, 13 Mar 2026 06:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773410357; x=1774015157; 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=jkQxYDJ/fqj9oY7QWpa/xMQehKB5EfjV0laBIMwYETk=; b=FhtvxNdHdQQUMoluj48dS4qncQ8Ga937qqCYBIH3lR5C4u4neBazdQy2RX3gnQn4fd uihMazCPWX95obOgk4XWsCCQriE/71MokVt5aafuXhejlg8z5sbcP2x+kTCV5akrxpFL c55tKc5AKqxw5CMnsHJx+QmB78GjD41MulAOMFs4tsZLwOI8U8Ibh4qV1AdBaoOjTt46 5hiAtRQzsSNXuay2ABZibkID0u5+UBgubBE9nlyvye7bTksiorIIXTlWJpvlRtp5jvlw W9seW8CNb1iQKiU5UqXjiFcszriZIT07JXuH4jaeSFc30+9td7/+23fJ8MMY7Edhnt9z 5OjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773410357; x=1774015157; 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=jkQxYDJ/fqj9oY7QWpa/xMQehKB5EfjV0laBIMwYETk=; b=mKzU5obZMLHjJ4o4AaVuKt8wA7iOm4DSU3OWEoJHewtv62DPkF3vC+gPuB0PZbX7KL I915WRXs1x5F6X9twSmE3IMPho1GqKsY820qfuKR/K0YjDIZwHilnNm7f7CzHRyIGkCC 7JfJuY6JY+drxZ2BcM75yRYMaZv6D3y2yrWHUgfKZgENzx9Gi9d9EJX4BkiZ8BgQx9me QFHlu5ymFzca1XOQntAErOkIzSu3T+4wsvMfE7C7XF/TEBMZoFNxgn7O09VtnAuR33ib urMPGxPgVVzilMpuAGMHFfowGDh7CSkZ5xsGfOYfN+ulsTG/xNmcTAiUQBojAioM8kHs H0Fg== X-Gm-Message-State: AOJu0YyQ6tGqbKjzTZvZs/ciUvRh60vUrTtSvSIJWtVwZHAPuYDhFX5U VPWLZS9qgtBt8BR0kDxGVh0+cI4dLnH8T2YN4yzQypkykwXac+PKjqyncpeCquQsD0Q0+IwL+cV YPs5d X-Gm-Gg: ATEYQzwVeSRVS8F/AwIqWCSgmQaYiaaj56pht6WmdTPlBd+bmN9T2S0m8g8ic06/fVG XYJE/T4RchzKDhQpsv7d90oeLygbDPzc4VXQWjW8HG3kwKyxY43LmlZl98WeyAwbaNUyr7p1pK4 Hos2ir3IdaUZEYiTeLaU6Kij+7sfUoJ9k5P6Pw7hU+DxIPMjEsNL19kQe3DXfOVSFlx6eLjhI3v l/qpQjpYYBdXWq76YQ4Obtz3d/lGEi8CYe2ajSC5btAkZV2ipf7kUgHexk+MNIuGVVqkP+UmEuy iQUu5/uWW9Cc2OIqfV0Tr8uSvcmtpKaPo1Sf10dRAl9ZU3Y7aT0zCk1kw61lVsx7R/cfVWE01Nr 3d4ZBzjAkMX1I3eW+1wxlO6cesiz0ZT+XZ0CMoS2dfKgfIG6dYYZZEPhk5Dv40ke0Z8MmEvTw5g v0drtMTkLnpsicIRl7xDbWgu/C7mBQ1rSnigbdm1dyRHReyqdZIy1P0MasWP8n4zkgy8bgEpXZg CgjxGemc735fARbfHzPJg9J+nxbNuc= X-Received: by 2002:a05:7022:6283:b0:122:153:d161 with SMTP id a92af1059eb24-128f3d7b662mr1856388c88.17.1773410356653; Fri, 13 Mar 2026 06:59:16 -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 a92af1059eb24-128f63baa3dsm2417528c88.15.2026.03.13.06.59.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Mar 2026 06:59:15 -0700 (PDT) Message-ID: <2d5de14a-17d2-4d08-992e-cbc5d430e231@linaro.org> Date: Fri, 13 Mar 2026 10:59:11 -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> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <660c10e6-f8b5-46e2-a424-e3e052992b3a@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12/03/26 18:01, Roman Bakshansky wrote: > Hi all, > > I'd like to share a draft RFC proposing a complete overhaul of the legacy > binary logs used for authentication auditing in Linux: lastlog, btmp, utmp, > and wtmp. > > These files, designed decades ago, are running into fundamental limitations: > > - Y2038 problem - they use 32-bit timestamps (time_t in lastlog, >   tv_sec in utmpx). Even on 64-bit systems the fields remain 32-bit >   due to ABI constraints, so all Linux systems are affected. > - No extensibility - any new field (e.g., container ID, service name, >   source IP) requires changing fixed structures, breaking all existing >   tools that read them. > - Poor query performance - tools like last, lastb, who have to >   scan whole files linearly; with millions of records this becomes >   painfully slow. > - No atomicity - partial writes during a crash can corrupt logs. > - Concurrency bottlenecks - multiple writers (sshd, login, etc.) >   contend for the same file with coarse locking. > > To address this once and for all, the RFC proposes replacing these logs > with dedicated shared libraries that use SQLite as the storage backend: > > - liblastlog2 - last login time > - libbtmp2    - failed login attempts > - libutmp2    - current sessions > - libwtmp2    - login/logout history > > SQLite brings: > - 64-bit time -> Y2038 solved forever. > - Indexes -> O(log N) queries instead of full scans. > - Extensible schema -> new fields can be added without breaking old tools. > - ACID and WAL mode -> atomic writes and concurrent access. > - Portability - runs on any Linux system, no systemd dependency. > > The full RFC, including preliminary database schemas and API drafts, > is available in the discussion repository: > >     https://github.com/bakshansky/linux-auth-logs > > I'm looking for feedback on the overall direction, the proposed > interfaces, and the open questions listed in the document (e.g., > library naming, database location, fallback options for embedded > systems). Please use GitHub Issues for comments, or reply to this > thread - I'll monitor both. > > Thanks for your time and input! >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/