Yep, for sure. Which is bummer for Fedora IMHO (for this specific topic).
1 Like
Personally, I would avoid depending on dbus.
It sounds like something that might fit into the fifth GECOS field?
1 Like
I’d even go so far as to make two points (or two cents):
- RHEL end-users and use cases are vastly different than Fedora’s.
- Fedora is not in the for-profit business/market
- Fedora doesn’t have or shouldn’t have the same set of compliance requirements/obligations. If Big Red needs those things, then let them add them to their OS.
3 Likes
Hi Greg,
I think IF Linux/Fedora was going to do this verification thing, that the /etc/group would be a good place to do it because the /etc/passwd field 5 (GECOS) is a bit to free-form. Just adding a group and sticking members into it would be pretty consistent … something like group (under18:x:65530:little_boby or underage:x:65530:resident_teenager,little_suzy) would be pretty simple and consistent across the platform…
2 Likes
I was thinking along the lines of being compatible with LDAP and various other systems out there, but I guess reserving some special group names would work too.
That GECOS field isn’t well handled by the small number of applications that currently reference it. I’m not sure if that would be a problem or if implementing this requirement would serve as an excuse to fix up those few old apps.
One problem with the GECOS field is that there is no way to “escape” a comma. IMO, it ought to follow LDAP’s lead and allow encoding ASCII chars with \XX. Just my two cents. 
1 Like
I think the mysterious 5th field would be useful as a proof of concept but i doubt its going to be reasonable as an ecosystem wide standard.
More realistically… if the the existing GNOME Parent Controls isn’t already sufficient for the purposes of the new legislation… it could probably be most easily extended to meet sufficiency conditions.
GNOME parent controls already have a notion of age buckets in the “Application Suitability” pull down in the interface which map to application policy involving OARS (Open Age Ratings Service) application ratings. It looks like its implemented via the malcontent package, which involves a dbus service extension to the accounts services daemon. What exists right now may provide sufficient control so that application store application (GNOME Software) can interact with application sources that expose the necessary OARS metadata.
3 Likes
Systemd already has an extensible user database service that this could use.
No need to hack on the legacy group or passwd files.
1 Like
Hi Barry,
Adding another group to /etc/group file is actually what the file is supposed to be used for 
… not a hack … and it would also be compatible with Greg’s thoughts on putting it in LDAP because the POSIX group template supports the same format/information AND both are easily searchable and exist on pretty much any UNIX/Linux system in existence … the systemd user database only exists on platforms that use systemd and it’s nowhere as easy to reference as /etc/group or LDAP … IMHO at least
Can’t get much simpler/easier/consistent than doing some logic that goes something like:
- Does the underAge group exist in /etc/group?
yes => is specified user in that group?
yes => restrict user to (whatever) or allow/disallow access to requested thing - NO=> create the underAge group in /etc/group as GID 65530 or highest available GID
- IF user is marked/flagged as underAge, add user ID to underAge group
Don’t need to rely on systemd, GNOME or any other non-POSIX implementation (which was the point of POSIX to start with)
About the only real problem is “Can everybody agree on what to call the group?” AND
getting the various S/W mfgs/devs to actually us it …
… what about systems that don’t run GNOME?
1 Like
All Fedora users run the authorised editions (Gnome and KDE),
No we don’t. I’ve been running Fedora with Xfce since slightly before Gnome 3 came out and have no desire to go back to Gnome. I very much doubt that I’m the only person like this.
3 Likes
As I see it, you will have to register the actual birth date. Only then will the system be able to determine the current age group of an account.
To put an account in a specific linux group will not work or at least lead to a lot of administration. John Doe may be in one age group today but will be in another tomorrow because it is his birthday.
FYI: There is a active discussion on Fedora Devel email list about an API being added to support this and future legal needs around age.
The discussion is bringing in other distro as well.
1 Like
The road to hell is paved with good intentions
5 Likes
Maybe they should target the companies and individuals catering to corruption of minors before trying to collect more data they can’t realistically do anything with from unconnected users 
2 Likes
I don’t think anything in the bills would allow us to ignore non-desktop users either. So most likely we should consider extending shadow to have an extra field for birthday so it can be exported to everything and handled as appropriate. This would also map cleanly to LDAP schema too.
For example, Cockpit needs to be able to configure this when creating users too.
2 Likes
I have so many questions
How would this work …
- on VMs?
- on Containers?
- on Cloud Infrastructure?
- on Refrigerators?
- on Cyber Cafes?
- on Watches?
- on weird old hardware that you can turn into a usable computer by installing an old patched version of the Kernel?
And what about the user? How would this affect accounts created for
- demo kiosks on sales show rooms?
- software specific accounts?
- school / university labs?
- workshops?
- AI agent / software crawler managed accounts?
Now, if implementation is on Fedora’s side… would we need to implement a solution that could work this on all of our spins? What about DEs that don’t have a Spin, but can be installed through the package manager? What if different DEs start implementing their own solutions?
If using the data used by requesting the signal is liable to be punished… what about extracting the data through other means? Or if the information is exposed as something as simple to parse as a user group or dbus message … wouldn’t it cause for other apps that expose this information to be liable too?
This is so weird…
7 Likes
I don’t think the system is supposed to “determine” the over/under age status. The user is expected to (re)set that status and, liability-wise, that is probably the way it needs to be.
It is, because it needs to create a less-precise “age signal” to expose.
1 Like
It’s better if the more precise data is never stored isn’t it? I don’t see why the onus should be on the system to calculate anything? Mind you, I haven’t read the actual legislation.