Forgot your password?
typodupeerror
Linux

SystemD Adds Optional 'birthDate' Field for Age Verification to JSON User Records (itsfoss.com) 118

"The systemd project merged a pull request adding a new birthDate field to the JSON user records managed by userdb in response to the age verification laws of California, Colorado, and Brazil," reports the blog It's FOSS.

They note that the field "can only be set by administrators, not by users themselves" — it's the same record that already holds metadata like realName, emailAddress, and location: Lennart Poettering, the creator of systemd, has clarified that this change is "an optional field in the userdb JSON object. It's not a policy engine, not an API for apps. We just define the field, so that it's standardized iff people want to store the date there, but it's entirely optional. "

In simple words, this is something that adds a new, optional field that can then be used by other open source projects like xdg-desktop-portal to build age verification compliance on top of, without systemd itself doing anything with the data or making it mandatory to provide. A merge request asking for this change to be repealed was struck down by Lennart, who gave the above-mentioned reasoning behind this, and further noted that people were misunderstanding what systemd is trying to do here.

"It enforces zero policy," Poettering said. "It leaves that up for other parts of the system."

SystemD Adds Optional 'birthDate' Field for Age Verification to JSON User Records

Comments Filter:
  • by abulafia ( 7826 ) on Saturday March 21, 2026 @11:44AM (#66053244)
    "It enforces zero policy," Poettering said. "It leaves that up for other parts of the system."

    "Calm down, stop being so jumpy. The explosives around your neck will not detonate. Unless I push this button."

    • Unless someone else pushes this button. And the necklace is optional anyway, your admin doesn't have to actually make to wear it.
    • by AmiMoJo ( 196126 )

      That does seem like an insane over-reaction. There are commercial Linux distros that don't have the luxury of simply blocking or ignoring countries that require age verification. Nobody is forcing you to use them, or any other distro that decides to use this field. In fact I've noticed a couple of distros now have messages on their websites saying that California is blocked.

      Do you worry because your CPU has crypto acceleration, which means ransonware can lock up your files even faster?

      • by Bahbus ( 1180627 )

        There are commercial Linux distros that don't have the luxury of simply blocking or ignoring countries that require age verification.

        No.

      • by DewDude ( 537374 )

        It's a form of forced compliance. It's a core operating system component taking the decision out and going "we're going to build it in to this thing everyone uses".

        "We came up with this stuff...called Secure Boot? We're not going to require it yet...but it's a nice idea."
        "Hey...we have OS level encryption. It's only going to be forced on users who organizations require it."
        "Hey..this nifty login can help you use sync your stuff...but use it if you want."

        Now...how many of those still hold water? You can turn

        • by AmiMoJo ( 196126 )

          So it's a slippery slope fallacy.

          Secure Boot is a good example. The predicted lockdown never came. You can still boot Linux on consumer hardware. Even pre builts and Macs. On fact you can use Secure Boot to secure Linux. It's had a huge positive effect on security for millions of people too.

          • No, it's not "slippery slope", and it's not a fallacy. The reason Secure Boot is still not locked down is because of the massive reactions to it, and the way its use is being monitored by cadres of both security professionals and enterprise money who have a vested interest in it actually providing increased security and not blocking their use case.

            There is neither any such use case, or any such interests, involved in this case. The functionality is added for no other reason than surveillance. It has no othe

          • Secure Boot is a good example. The predicted lockdown never came. You can still boot Linux on consumer hardware.

            On many laptops. Most phones consumer completely lock out Linux.

            • by AmiMoJo ( 196126 )

              I haven't looked lately, but don't most of them allow unlocking the bootloader? Lineage or whatever it's called now still seems to be a going concern.

        • > Linux is the only OS left that hasn't forced you in to online accounts...with cloud storage

          "Linux" isn't an OS, it's a kernel. The distinction is important here because both ChromeOS and Android do, actually, require online accounts and cloud storage. And last I heard, macOS doesn't require either, an Apple ID is needed only for certain Apple services, and there's no obligation you log in if you don't actually choose to use those services. And those services are the type of service where you'd need som

    • Apparently already contains “realName”, and “location”. I happen to think both of which are worse than date of birth but all this is obviously in many databases that feature me.

      • by DewDude ( 537374 )

        Those fields have existed as part of user logins on UNIX since the very early days. The operating system's roots are in a very different time. Depending on the particular system it may have wanted things like Name, Badge ID, Office Number, Home Number, Department....etc

        realName and location have exited for probably over 50 years in the *NIX world. You don't break legacy if you can avoid it.

        • by Anonymous Coward

          You don't break legacy if you can avoid it.

          SystemD

        • But you can avoid it easily and just make them stubs and have it all return a default nonsense value. This is in general the issue I feel with a lot of this “only privacy” talk; the “legacy” far more serious things all those people seemingly don't care about which they could easily mitigate. It's like politicians caring about cannabis when a significant portion of their country habitually partakes in alcohol, including themselves.

          Like politicians caring about cookies and how they're

  • Love systemd (Score:3, Interesting)

    by karmawarrior ( 311177 ) on Saturday March 21, 2026 @11:52AM (#66053254) Journal

    SystemD has genuinely been a positive on the computers I administer and has saved my butt multiple times. I had numerous occasions with sysvinit where "dependencies" had to be implemented using "sleep" commands in shell scripts and as a result the system wouldn't come up properly. So please do not take this as one of the tribal kneejerk anti-SystemD people.

    But... this is idiotic, and SystemD is rapidly turning into a parody of itself. The other week they announced they were integrating a whole new "VM" system into SystemD (add that to VirtualBox, KVM, Xen, LXD/Incus, etc...) Why? All of the existing VM management systems can easily have their own .service files, why does SystemD need to have its own? It doesn't.

    They really need to pull back and ask themselves why they're virtually giving ammunition to the weird SysVInit cultists. Because this is ammunition.

    • by haruchai ( 17472 )

      Poettering is trying to implement Emacs inside the kernel

    • Re:Love systemd (Score:5, Interesting)

      by PPH ( 736903 ) on Saturday March 21, 2026 @12:39PM (#66053320)

      But... this is idiotic, and SystemD is rapidly turning into a parody of itself.

      You are starting to understand why the systemd haters think like they do. If Poettering had proposed a drop-in replacement for SysV init and then stopped, I would have thought, "Why not?" But we got a hairball of event-logging, network management, file mounting, user authentication crap all bundled in.

      But what really sank it was when I discovered that it was relatively simple to launch SysV shell scripts from the unit files to start services, thus saving all the work involved in re-inventing the wheel. And the systemd fans came absolutely unglued when I posted that. Sorry. Linux, and all the other UNIXes involve collections of simple "do one thing well" applications that can be tied together, at times with pipes, files and other tools. And you can't tell developers what tools or languages to use. If you want an OS that is becomming one giant EXE to dynamically load and run everything as a DLL, go use Windows*.

      *I had to repair someone's Windows 10 system (barf emoji) after a Microsoft update attempted to cripple it (just upgrade to Windows 11, they say). I was amazed at how much of that involved command line stuff. So much for your Utopia.

      • Doing only one thing, and doing it well was a well known Unix philosophy. But did it ever get adapted in Linux? Did Torvalds ever endorse it?

        • by PPH ( 736903 )

          Did Torvalds ever endorse it?

          Explicitly? I don't know. But Linus is in charge of the kernel. And in the world of GNU/Linux, that's "one thing". I do know he generally stayed out of most of the fights concerning other parts of the distros.

          Although it remains to be seen what he might have to say about systemd wrapping itself around kernel booting and module loading.

      • You are starting to understand why the systemd haters think like they do. If Poettering had proposed a drop-in replacement for SysV init and then stopped, I would have thought, "Why not?" But we got a hairball of event-logging, network management, file mounting, user authentication crap all bundled in.

        People implemented this and it ended up being a horrible half-baked solution which is why the alternative init systems never went anywhere. Instead of raging about features ask why they exist:

        - event-logging - a logging system tied to service management system not only makes perfect sense, but systemd's logging is able to capture logs prior to the startup of any event logger - i.e. the "old" way literally lacked the capability to log some things. And in the implementation systemd offers a way to dump all lo

        • You are starting to understand why the systemd haters think like they do. If Poettering had proposed a drop-in replacement for SysV init and then stopped, I would have thought, "Why not?" But we got a hairball of event-logging, network management, file mounting, user authentication crap all bundled in.

          - event-logging - a logging system tied to service management system not only makes perfect sense, but systemd's logging is able to capture logs prior to the startup of any event logger - i.e. the "old" way literally lacked the capability to log some things. And in the implementation systemd offers a way to dump all logs to the traditional logging system. ALL of them. I.e. even if you never want to touch the journal, its existence still makes other logging daemons better.

          Can't say journald really works based on my very recent experience. Ubuntu did an upgrade to my 24.04 LTS system. When I rebooted after that all I got were black screens, not even a mouse pointer, which told me X wasn't running. I could ssh into the system just fine, which is why I could tell that the logs were worthless as there weren't any errors shown, or at least nothing about video just some apparmor warnings. Eventually I figured out that the upgrade broke the Nouveau (the OSS nvidia) driver. I'd been

      • I have great news for you! Systemd version 60 removes support for SysV init scripts!
        • by PPH ( 736903 )

          Systemd version 60 removes support for SysV init scripts!

          Do you mean version 260?

          And you do know that the SysV init scripts are actually run by bash. Are you certain that nobody has figured out a way to get systemd to run any old executable ELF binary. Like bash?

          • Google is your friend.Try: "systemd 360 init script changes"

            "Based on recent major updates (specifically systemd 260+), support for legacy System V (SysV) init scripts in /etc/init.d has been removed, making native unit files mandatory. Users must replace old shell scripts with unit files, which use declarative [Unit], [Service], and [Install] sections to handle service management, dependencies, and parallel execution."

            So yes, I should have wrote 260 rater than 60. I didn't say nobody could "find a way", I

            • So yes, I should have wrote 260 rater than 60. I didn't say nobody could "find a way", I said they are removing support.

              But they are not. Unit files can still call init scripts, so they are not removing support for init scripts. They are only requiring that you use unit files with them. It's too bad you don't understand what any of these words mean. Since systemd is still based on Unix and not the other way around so far, they haven't stopped scripting from working yet. Expect that in a future version.

              • Nobody ever said they are disabling bash. Nobody said you can't runs scripts via unit files. If you knew how init worked you would know what init.d is, how it works, and why no longer using it is removing support. They are not removing support for scripts. They are removing support for the init script mechanism, implemented by numbering your scripts and putting them in init.d. Systemd, up until v260 supported that mechanism. Stop pretending you have a clue, when you have no idea what you are talking abou
                • If you knew how init worked you would know what init.d is, how it works, and why no longer using it is removing support

                  Since I know how Unix works I know init.d is just a directory, what's in it is just script files, and they can be called by unit scripts.

                  They are removing support for the init script mechanism, implemented by numbering your scripts and putting them in init.d.

                  Yes, exactly, they are shitting on the right way to do things because it demonstrates how there's no need for them to exist.

                  Stop pretending you have a clue, when you have no idea what you are talking about.

                  You still don't know what the words you are using mean, but that doesn't stop you.

                  • I'm not about to continue a discussion with someone who is too stupid to figure out that they just contradicted themselves in a post comprised of only three sentences.
                • by PPH ( 736903 )

                  Nobody said you can't runs scripts via unit files.

                  Thank goodness. So all I need is one unit file to run /etc/init.d/rc

    • A VM? A hypervisor you mean? Don't they need some sort of a kernel to implement that?

    • People were saying that since the inception of systemd. Why write binary logs and develop special new tools to manipulate these logs when the old tools did the same thing with plain text for decades.

    • But... this is idiotic, and SystemD is rapidly turning into a parody of itself.

      Actually this isn't idiotic at all, SystemD already has a service that manages users and their logins called systemd-logind, and that is actively used by several distributions. Having a field tied to the user identity on a system level makes sense, and for distros which use logind this is the perfect place for it, it's why systemd already has a user record management system in the first place.

      Ultimately this change has nothing to do with the init part of it at all, so anyone responding to this with any comp

      • You do know that systemd version 60 removes support for SysV style init scripts, right? I do agree that it isn't related to this change, but it IS related to Systemd rapidly becoming a shitshow, so there is a correlation to the complaint.
        • by allo ( 1728082 )

          This was clear from the start. "You don't need to change anything, systemd will just use your scripts"
          Yeah, until you deprecate that. Now it doesn't even run rc.local.

        • by gweihir ( 88907 )

          Well, looks like I was more than justified to remove systemd from all my installations early on. These people creep in with empty promises and lies and at some point it becomes obvious that they are really trying to do a hostile takeover.

          Incidentally, I am still at zero init-system related problems on all my non-systemd installations.

          • You are clearly "throw the baby out with the bathwater" kind of guy. Systemd still has huge advantages over init scripts, and you don't have to build the entire feature set in. This is like you finding about a portage variable getting added to Gentoo and saying "See, I knew Gentoo sucks!"
            • You are clearly "throw the baby out with the bathwater" kind of guy. Systemd still has huge advantages over init scripts

              AHHAHAHAHAHAHAHAHHAHAHA

              This is like you finding about a portage variable getting added to Gentoo and saying "See, I knew Gentoo sucks!"

              What sucks about Gentoo is that they move fast and break things so you can follow the instructions while using even completely innocuous USE flags and still have the install fail because some critical component doesn't build. As such you basically have to do a binary install before you can actually build your system the way you want it.

            • by gweihir ( 88907 )

              Nope. I am the "if it is not broken, do not fix it" person. I yet have to see any advantage to systemd. I am missing exactly nothing with my current set-up.

              You are clearly a propaganda victim and not very smart.

              • So you don't use systemd and have yet to see any advantage using systemd. That logic checks out! Herp Derp.
                • by gweihir ( 88907 )

                  Your mental temperature is really according to your username, isn't it? I am sure you are unable to do so, but other people can read documentation and feature lists and experiences others made and understand whether they have any problems or shortcomings in their current set-up that would likely be fixed by a move. And I do not have any such issues. Things work fine, everything is reliable and stable, my own init-scripts cause zero problems and everything is just as it should be.

                  All you are doing is add ano

                  • I know. I know. You are truly an amazing and brilliant man. There is no reason to use systemd. The vast majority of the Linux community are idiots. If only they were smart like you. Herp Derp.
    • by sjames ( 1099 )

      Back before systemD was even a consideration, I just wrote a wrapper script that waited until a dependency was ready, then started the dependent daemon.

      Parallel start-up was a thing before systemD as well.

      I wouldn't mind so much if systemD would stay in it's lane and just be an init system.

      • by allo ( 1728082 )

        Service managers are great and using cgroups for that is the right tool. The problem with systemd is adding more feature before the old ones work halfway decent. And adding features that should be independent programs in the best case by independent developers.

      • by gweihir ( 88907 )

        I wouldn't mind so much if systemD would stay in it's lane and just be an init system.

        Well, if it did that you could simply replace it if it starts to cause trouble. The people behind systemd do not want you to have that freedom.

    • Re:Love systemd (Score:4, Interesting)

      by MeNeXT ( 200840 ) on Saturday March 21, 2026 @03:26PM (#66053564)

      I've been administering systems remotely, thousands of miles apart, for over 30 years and never had an issue with systems not coming up until SystemD was introduced.

      I'm not saying it hasn't happened to you but the choices you make generate your results. I prioritize stability, reliability and security so I never had an issue.

      Labels like 'tribal kneejerk anti-SystemD people" don't help the converstation. There are people who believe their is a right tool for the job. A Swiss army knife is great for emergencies but you never see a carpenter using it as a main tool.

      • by gweihir ( 88907 )

        Indeed. The only init-related problems (besides me writing buggy init-scrips before I really understood them) are from systemd shortcomings when I initially looked at it. Decided then and there to not move and I still have had zero problems from that. I did avoid some catastrophes though. For example, the demented decision to patch libsystemd into sshd by some Debian "maintainers" did not hit me because the libsystemd on my systems is just a stub.

        At this time, if you want a reliable, secure and well maintai

    • by gweihir ( 88907 )

      the weird SysVInit cultists.

      You just removed all value from your statements right there.

      While I do not know who messed up your sysvinit scripts, the init system, and the scripts running under it are two different things.

    • I've heard your argument of 'you just can't do that with sysvinit', but no one has ever done more than state that superficially ... bringing up networks in a specified order is the main argument I've heard, but I run multi homed systems with sysvinit on devuan, and don't have any problems ... help me out here . Explain to me what specific use cases that only systemd can do?
    • They really need to pull back and ask themselves why they're virtually giving ammunition to the weird SysVInit cultists. Because this is ammunition.

      You have eaten so much propaganda that you are like a walking billboard. The people who have an active dislike for SystemD are not SysVInit cultists. SystemD just sucks so badly, that SysVInit looks "good" in comparison. It is you who think that people love SysVInit and you do that as a defense against the knowledge that SystemD is inferior. Take a moment to step back and look around. SystemD is pure garbage which will have architectural failures throughout its entire life. SysVinit will suffer similar issu

  • Enforces no policy (Score:5, Insightful)

    by nicolaiplum ( 169077 ) on Saturday March 21, 2026 @11:56AM (#66053256)

    ... yet supports the easy implementation of bad policy beforehand. Technical choices are policy choices, Lennart. You can't get away from that.

    This is all in line with the systemd attitude: more monolithic, less extendable or modular. More like Windows, less like UNIX.

    • by gweihir ( 88907 )

      More like Windows, less like UNIX.

      Indeed. That is it in a nutshell. And look where Windows is going these days. Linux should really not follow that direction.

  • It won't need the user anymore. Makes me think of the Dean Koontz novel Demon Seed.
  • Would incorporate age verification and I was down-modded. Doesn't seem so far fetched now, does it?
  • The enforce policy
    He likes to do things stepwise

  • I note that you can only enter an exact date into this system. As well as allowing users to be ambiguous, (for instance, if you want to broadcast being over 18 only,) some people don't know their exact birth date and would need a range.
  • You know, age 63 and up. They're the remaining people that can tell the time from an analog display, like a wrist watch.

    Okay, Boomer signing off before this californi-age-verification creeps into those once-promising genealogy applications and f-all else besides.

  • Legal landmine (Score:5, Interesting)

    by OrangeTide ( 124937 ) on Saturday March 21, 2026 @12:26PM (#66053294) Homepage Journal

    California (AB-1043) and Colorado (SB26-051) may seem to require age verification. But US federal law, the Privacy Act of 1974, seemingly contradicts this. If states are effectively deputizing every operating system to collect information and deliver it ad hoc through intermediates, it still violates the spirit and principle of this federal act.

    The fact that this particular implementation in SystemD stores the new birthDate field in the
    regular (non-privileged) JSON. Meaning that there is little user control over which applications get access to this information.
    If at the very least, the user was able to control access to PII in their SystemD / unix accounts, then I think they would potentially have a legal leg to stand on.

    As they stand right now, we're only a lawsuit away from reverting the change in the git repo. No need to fork, if SystemD wants to bend over backwards for California and Colorado law so badly, then we can take them to court in the US. Honestly, taking them to court in California would probably be the most effective right now.

  • Nobody in CA or CO is verifying the number.

    Yet.

  • How unsurprising. What is surprising is that his fanboys haven't yet realized that he's a clueless ignorant newbie with delusions of grandeur -- someone who actually thinks he knows better than the people who've won pretty much every prize in computing, including the Turing Award.
    • Somebody needs to organize a group to raise funds and organize a way out of Poettering's over reach and over complication of the OS.

      I'm fine with a standardized birthdate... and more standard conventions!
      I object to the simplistic thoughtlessness of this. A full DATE shouldn't be required! somebody needs to design this with some thought!

      Privacy is not served with a date. I suppose at least he didn't make it a timestamp right?? or could we have that level of detail?? that would allow some serious fingerpr

      • An adult flag doesn't work.
        People who aren't adults turn into adults based on their birthday and their location and the context.
        The OS can know all of these things and return a flag.

        • The admin enters this info even in the current birthday setup! So the admin has to also update status changes. The OS only needs to record what humans enter into it and the PURPOSE is to know if somebody is a legal adult. That is ALL the info that is required for the feature. No more is required and adds more troubles.

          This is a simple boolean flip and adult status is permanent no matter how childish somebody behaves; it does not need to be automated. As if an admin can't use automation on a linux system..

        • by allo ( 1728082 )

          Why does this need to be managed by the system? Parents create children's accounts and parents change when they become full accounts. If the system should manage that, the next step would be the system to verify that, because politicians wanting that control won't be satisfied by "now someone added a date that implies the person is overage" but see that this is not enough for what they wanted. Thinking "this won't work because I enter fake data" is false security as it depends on assuming nobody will add mo

        • by gweihir ( 88907 )

          You are aware that you can run Linux with a different clock setting and that it does not even require a location setting at all, right?

        • by thogard ( 43403 )

          I'm in favor of fixing this properly before the politicians mandate something stupid.
          My proposal is a sysctl value set by a pam module (or systemd on systems infected with that). The browser then does something like language verification much like the HTTP Language headers. Those can be intercepted, checked or forced in environments that have to provide web access to kids like schools. A web site should be able to ask for something like Australia's under 16 and can return a AGE_AU_VIC_Under_16=True if an

          • I'm in favor of fixing this properly before the politicians mandate something stupid.

            You then went on to describe something stupid: Allowing the operating system to participate in this madness in the first place. The OS is there to interface my applications to the system, not to share PII about me. Fuck all the way off with that sycophantic bullshit.

    • by gweihir ( 88907 )

      People are dumb and ignorant, and most do not change their views when presented with hard facts that contradict them. The Linux community used to be better, but since the influx of tons of Windows people (Poettering among them), it has become less and less of a rational meritocracy, to the detriment of its engineering quality. Fortunately, you can still stay away from crap like systemd pretty easily.

  • by thedarb ( 181754 ) on Saturday March 21, 2026 @01:19PM (#66053368)

    Collaborator

  • I'm not giving you my date of birth. How about a single boolean thing: `adult`: yes / no End of story. I'm not entering my name, date of birth, sexual preference, religion, etc, etc, in my computer in order to use the Internet. The companies that demand it, are usually also the ones getting hacked and leaking my data.... Luckily they all "value my privacy"... Hell Nah.
    • by gweihir ( 88907 )

      When asked for my date of birth, I usually just lie and make something up. The only exception is credit-card verification, but that is, by law, done by a provider under PCIDSS that may not give that data to the site it is embedded in. The GDPR is strict on such things.

  • SystemD is incorporating an automated payment plan into the existing system. It was heard that "This is consistent with our future plans" but Bob the Bum outside, laying on the pavement.
  • Problem solved as long no less than 18 year old has root or is too dumb to mount and modify a drive.

    Simple, easy to read by EVERY application just as the state wants. And really easy to modify as every underage user wants.

    • by allo ( 1728082 )

      And every user knows the birth date of every other user.

      • by gweihir ( 88907 )

        To prevent that, put it into /etc/shadow instead. But the whole idea is deeply flawed. I can just boot Linux from a stick and be root on it and there is no way to prevent that. And suddenly, I can claim any age I want and this does not even require installation on a computer.

        • by allo ( 1728082 )

          That's alternating between software and laws.
          - Law: Age verification
          - Software: Systemd
          - Law: Cannot prevented
          - Software: Secure Boot with age verification

          People think they are clever because the current implemention is insecure, but the people making the laws see if their law is inefficient and double down. And if the developers comply, they get what they want. This most importantly needs political backlash, but developers being slow, unmotivated, and inefficient to implement it also helps a bit. Systemd l

  • I guess I wouldn't have had a solid 10+ years of experience with Linux, either. I started with Caldera Linux 1.2... way long ago. And BeOS, too, way before I was 18...

  • Who is the family member installing a Linux distro containing systemd? Junior has admin rights, sets the age data, and Bob's his uncle. This is the basic problem with all possible systems that are not beyond belief privacy invasions.

    As for me, I figure I can set two accounts, one that shows me as a late 18 year old, if I want to snoop on 'em, and the other that shows a random age between 21 and 121 when I want to make as close a run on honesty despite unconstitutional levels of privacy invasion.

    {^_^}

  • by HnT ( 306652 )

    Why is everyone suddenly so extremely gung-ho in pushing this boiling-the-frog?

  • Not-so-fun fact: 87% of US citizens can be identified with gender, ZIP code, and full DOB.

    https://pmc.ncbi.nlm.nih.gov/a... [nih.gov]

  • Darth Vader: Lennart Poettering
    Death Star: SystemD
    Emperor Palpatine: The Linux Foundation
    Obi-Wan Kenobi: Richard Stallman
    Wayland: Kylo Ren
  • I only sold them the wood for the gallows.

    See? I don't set policy. I just follow orders.

"Being against torture ought to be sort of a bipartisan thing." -- Karl Lehenbauer

Working...