Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On Sat, Jun 27, 2020, at 5:43 AM, Rich Freeman wrote: > But, as I said, using more uids/gids in general means having more > separation. In general it only increases security, with the caveat > that it does potentially make auditing more complex. > Android's security model is uid per app. This is about as effective you can get on a mostly stock kernel. There is essentially no isolation within a uid. It's also why it is very hard to use an Android phone for anything without rooting it. If you look at the CVEs for Android they are typically rather benign, the more persistent issue is you constantly carry the device with you.
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On Fri, Jun 26, 2020 at 10:18 PM james wrote:
>
> On 6/26/20 4:40 PM, Rich Freeman wrote:
> > Removing the group doesn't actually make things more secure, because
> > processes can use a gid even if it doesn't exist in /etc/groups.
> > Effectively any POSIX system has every uid/gid available even if there
> > is no /etc/passwd at all.
>
> And that is coded into the parts of the kernel, we cannot eliminate?
> Typical sploits?
>
> Curiously, a bit deeper explanation?
So, ultimately a uid/gid is just a number, and a field in a couple of
tables. Inodes have them, and processes have them. There might be
other things that have them that I'm not thinking of, but those are
probably the main two.
If a process wants to send signals to another process the uids have to
match, or it must have a capability to break this rule. If a process
wants to read a file, the uid/gid/permissions/ACLs/etc must correspond
appropriately. I'm sure there are a bunch of other system calls where
uids/gids matter as well.
The field that stores the IDs has a certain size, and thus any number
within the expressible range is valid. You can't "get rid" of a UID
any more than you can ban the number 13. However, since the logic is
based on matching it really doesn't matter much - if you launch a
process with a UID you intended to be "unused" it basically is
completely isolated as far as the filesystem and other processes go
since its UID doesn't match anything else (it could still touch world
read/writeable files, but that is true if it ran under a UID you
preferred that it use).
The files /etc/passwd and /etc/group are used by various system
programs to map these IDs to human-readable names, but they really
aren't part of how the kernel works. Just about any command that can
take a username can take a user ID, and if you want to really drive
people crazy go ahead and try using numeric usernames (I believe the
IDs take precedence in command lines).
So, if you deleted /etc/{passwd,group,shadow} you could still have a
"perfectly working" linux userspace, but commands like login wouldn't
work as those use usernames and of course there would be no mapping to
passwords. However init would still run as uid 0, and it could launch
processes with other uids, and those processes would have regular
filesystem behavior. It wouldn't be POSIX and various things might
break, but you could have a name-less userspace just fine on linux.
The kernel itself never looks at /etc/shadow and so on - it just sees
numeric IDs. Android is an example of an OS that makes some
substantial changes in userspace to how things like UIDs are
traditionally used (that, and the OOM killer).
Most things associated with users/groups in linux are conventions
implemented in userspace.
But, as I said, using more uids/gids in general means having more
separation. In general it only increases security, with the caveat
that it does potentially make auditing more complex.
--
Rich
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 6/26/20 4:40 PM, Rich Freeman wrote: On Fri, Jun 26, 2020 at 4:03 PM james wrote: So can some of the smarter (gentoo) folks illuminate how to totally avoid groups and users, except for the minimum required, application specific? For example like serial line tools, or outline a set of tweaks/setting to avoid these altogether? IMO if extra security is your goal then if anything you want to have MORE use of users rather than less. Everything should be least privilege, and usually that means having separate UIDs for everything, and then layering on stuff like namespaces/SELinux/capabilities/etc on top of that to further tailor things. OK, that's a pathway forward, that I no longer believe in, though viable. I think the days of systems design and implementation, that require a default, multi-user, scenario, are arcane and subject to many attack vectors. Granted many will and do disagree, and new pathways are rarely well lighted in my experiences. Of course the more config you have like this, the more there is to audit. However, you also have to consider the failure mode. When you have layers of security and some layer fails, chances are that the failure still results in more containment than what you would have had if you didn't build the layers in the first place. Security Schema are many and all are under attack. Most of what I need from a 'well behaved' collective of microprocessors and microcontrollers are in-house and need little (data) from the outside. The need to share outside is nice, but can be limited, dynamically for a wide variety of reason. The deep desire to share, in part-and-parcel, is to be human. For me, as a christian, its far deeper of a need, but that on me. Quick and automated shut-off, is a concept I like very, very much. Currently, the need to be able to "snap my fingers" and instantly isolate, is mostly prevented because our USA government forces chip manufacturers to put "bullshit and backdoors" into most all processors and controllers. That shit has to STOP. They, including our F. Feds do not have that right. If we do not fix this, SATAN gets control; hence the end-times are upon us, like a thief in the night. That's my belief and I know many that think it is too late, to fix. the first step is to have 100% of critical systems components manufactured in the USA. Each country can and should do their own thing. Leaders have now realized, letting folks that rule the large corporations, "have it their way" has landed up in a pile of problems. Now, one thing that would result in fewer UIDs is installing less stuff. Maybe that is what you're getting at, and of course reducing the attack surface is a good thing. However, keep in mind that a UID in /etc/passwd doesn't actually do anything if no process runs with that UID - it is just a line in a text file. So, having a uucp group when no processes have access to it doesn't really cause issues. unless the remotes can inject into that causal hardware relationship and exploit it? Who knows what lurks in them micro-codes of silicon these days much of the hardware has hidden Rf channels, well hidden and it requires quite expensive systems that the semiconductor companies provide, mostly to governments, on a use-to-be limited basis. That's why the USA is forcing AMD to bring 7-nm manufacturing to US soil, so they are under USA rule-sets. Makes the Mafia look like choir boys.. here's one publicized: https://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/ and a bit deeper: https://freetechsforum.com/minix-%E2%80%8Bintels-hidden-chip-operating-system/ Removing the group doesn't actually make things more secure, because processes can use a gid even if it doesn't exist in /etc/groups. Effectively any POSIX system has every uid/gid available even if there is no /etc/passwd at all. And that is coded into the parts of the kernel, we cannot eliminate? Typical sploits? Curiously, a bit deeper explanation? I'm no expert at this stuff, but I am very interested to hear more, from your perspective and experiences which you are comfortable sharing. James
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 6/26/20 4:36 PM, Jack wrote: On 2020.06.26 16:03, james wrote: On 6/26/20 12:38 PM, Daniel Frey wrote: On 6/20/20 7:04 PM, William Kenworthy wrote: Thanks for filing the bug. Gah! I forgot about this! I filed a bug now, I hope I made it clear enough. Others can pipe in there with comments if they like. I did indicate the two potential proposals to correct the issue in the bug itself. https://bugs.gentoo.org/729752 Dan BEFORE I contribute to this bug, I'm posting here to see if others are or have interest, in my thoughts on this issue and my related needs for extreme security, via Gentoo. Below is far from complete, but it only provides a very snippets of my (secure) pathway forward with Gentoo. Interesting thread, thanks to all contributors. I'd like to add 'my selfish' interest, as they also be espoused by other, more focused, gentoo users. INTRO: I rarely build gentoo systems, for many reasons, that are not pretty singularly focused. It drastically reduces security, performance and upgrade issues. For me, the days of a any system, having groups or users, are in the history books of very bad ideas. uP are so cheap and less than $100, gets you a very 'bad ass' computer (Rasp. Pi 4+) 16 G map-able ram. Furthermore, SOON, usb_4 devices are going to obsolete the entire concept of a 'hard drive'; hence the death (my prediction) of groups and users on multi-USER systems, albeit slowly. Multi-function, Multi-tasking, and light weight, focused transient clusters are the future. YMMV. So solving a problem, that was real and big, decades ago, fails to look at the future. For me, Gentoo is future proof. I suggest a well documented pathway forward; totally without the concept of groups and users, on a typical, highly secure system. Which is now the baseline for real systems, particularly with a ipv4 or ipv6 static ip, that provide focused and highly restricted functionalities. CA servers are going private, as the public and root CA servers, are suspect, at best, as to being pristinely secure. Yes boys and girls most Certificate Authorities are HACK! Even the main root CAs. The F. Feds are the original culprits, but now it is a feeding frenzy. The planet is now hacked, and groups and users concepts are the past. imho! Danger Will Robinson Danger! So can some of the smarter (gentoo) folks illuminate how to totally avoid groups and users, except for the minimum required, application specific? For example like serial line tools, or outline a set of tweaks/setting to avoid these altogether? I build embedded G. systems. I build single purpose G systems. I build security G. systems (often with the ethernet, in only listen mode. I build G. Firewalls. I build G. highly restricted/filtered servers. NONE of those need users or groups. And if they do, I can obfuscate codes to provide that need, to where filters and focused software gets what it needs to provide functions. Yep, I'm moving to a total 'State_Machine_design' for critical services. Strip out every thing else. Am I alone, or have/are others contemplating such high secure pathways? I'd be fantastic to find a kernel hacker that is on the pathway of extreme minimization too; private email is fine; if that is in your wheel_house. curiously alone?, James While you may not be alone, I do believe you're in a rather small group.? There are probably more who are interested in watching it progress than who can actually participate and contribute.? And while what you propose may well be part of the future, and it may even be a large part of it, it won't be so anywhere near soon enough to avoid the need to continue to improve current systems, even if the improvements are only usability related, and not directly related to security. Yep, Yep Yep. Um, now covid hit. We've been promised much more from the next 'virus'. Massive security problems, for all OSes, dispersed computational issues and such. So, a vision (dream?) of total self sufficiency, with packets of really secure content traversing the fibers of the world, and a few smart, empower techies running a given hub, sure we can solve the security issues. However, the big webs are mere wide spots on the highway and should readily be "dynamically" replaceable; never critically necessary for any astute user. And the F. Feds and their overseas counterpart? Are left behind in the dust, for good. I think you'll see a US presidential candidate, whom constitutionally, recognzes the US citizens have a fundamental (God given?) right to superior security, as long as they have a very clean legal record. Boy that's a twist: well behave citizens get superior security righs to F. Feds? Boy, that's going to be a popular idea, methinks. Actually, there are many Christian lawyers, who know of ancient documents and USA historical documents and letters that expound on those documents, where this is well established. NO questions atm. Let
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 2020-06-26 16:03, james wrote: > > BEFORE I contribute to this bug, The bug is already fixed in a newer version of portage =)
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On Fri, Jun 26, 2020 at 4:03 PM james wrote: > > So can some of the smarter (gentoo) folks illuminate how to totally > avoid groups and users, except for the minimum required, application > specific? For example like serial line tools, or outline a set of > tweaks/setting to avoid these altogether? > IMO if extra security is your goal then if anything you want to have MORE use of users rather than less. Everything should be least privilege, and usually that means having separate UIDs for everything, and then layering on stuff like namespaces/SELinux/capabilities/etc on top of that to further tailor things. Of course the more config you have like this, the more there is to audit. However, you also have to consider the failure mode. When you have layers of security and some layer fails, chances are that the failure still results in more containment than what you would have had if you didn't build the layers in the first place. Now, one thing that would result in fewer UIDs is installing less stuff. Maybe that is what you're getting at, and of course reducing the attack surface is a good thing. However, keep in mind that a UID in /etc/passwd doesn't actually do anything if no process runs with that UID - it is just a line in a text file. So, having a uucp group when no processes have access to it doesn't really cause issues. Removing the group doesn't actually make things more secure, because processes can use a gid even if it doesn't exist in /etc/groups. Effectively any POSIX system has every uid/gid available even if there is no /etc/passwd at all. -- Rich
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 2020.06.26 16:03, james wrote: On 6/26/20 12:38 PM, Daniel Frey wrote: On 6/20/20 7:04 PM, William Kenworthy wrote: Thanks for filing the bug. Gah! I forgot about this! I filed a bug now, I hope I made it clear enough. Others can pipe in there with comments if they like. I did indicate the two potential proposals to correct the issue in the bug itself. https://bugs.gentoo.org/729752 Dan BEFORE I contribute to this bug, I'm posting here to see if others are or have interest, in my thoughts on this issue and my related needs for extreme security, via Gentoo. Below is far from complete, but it only provides a very snippets of my (secure) pathway forward with Gentoo. Interesting thread, thanks to all contributors. I'd like to add 'my selfish' interest, as they also be espoused by other, more focused, gentoo users. INTRO: I rarely build gentoo systems, for many reasons, that are not pretty singularly focused. It drastically reduces security, performance and upgrade issues. For me, the days of a any system, having groups or users, are in the history books of very bad ideas. uP are so cheap and less than $100, gets you a very 'bad ass' computer (Rasp. Pi 4+) 16 G map-able ram. Furthermore, SOON, usb_4 devices are going to obsolete the entire concept of a 'hard drive'; hence the death (my prediction) of groups and users on multi-USER systems, albeit slowly. Multi-function, Multi-tasking, and light weight, focused transient clusters are the future. YMMV. So solving a problem, that was real and big, decades ago, fails to look at the future. For me, Gentoo is future proof. I suggest a well documented pathway forward; totally without the concept of groups and users, on a typical, highly secure system. Which is now the baseline for real systems, particularly with a ipv4 or ipv6 static ip, that provide focused and highly restricted functionalities. CA servers are going private, as the public and root CA servers, are suspect, at best, as to being pristinely secure. Yes boys and girls most Certificate Authorities are HACK! Even the main root CAs. The F. Feds are the original culprits, but now it is a feeding frenzy. The planet is now hacked, and groups and users concepts are the past. imho! Danger Will Robinson Danger! So can some of the smarter (gentoo) folks illuminate how to totally avoid groups and users, except for the minimum required, application specific? For example like serial line tools, or outline a set of tweaks/setting to avoid these altogether? I build embedded G. systems. I build single purpose G systems. I build security G. systems (often with the ethernet, in only listen mode. I build G. Firewalls. I build G. highly restricted/filtered servers. NONE of those need users or groups. And if they do, I can obfuscate codes to provide that need, to where filters and focused software gets what it needs to provide functions. Yep, I'm moving to a total 'State_Machine_design' for critical services. Strip out every thing else. Am I alone, or have/are others contemplating such high secure pathways? I'd be fantastic to find a kernel hacker that is on the pathway of extreme minimization too; private email is fine; if that is in your wheel_house. curiously alone?, James While you may not be alone, I do believe you're in a rather small group. There are probably more who are interested in watching it progress than who can actually participate and contribute. And while what you propose may well be part of the future, and it may even be a large part of it, it won't be so anywhere near soon enough to avoid the need to continue to improve current systems, even if the improvements are only usability related, and not directly related to security. This current issue is nothing more than an annoyance, but it's a major annoyance for many Gentoo users, possibly more-so for the more casual users. (Is "casual Gentoo user" an oxymoron?) As the bug proposes, there are ways of solving it without decreasing security. Jack
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 26 June 2020 22:03:35 CEST, james wrote: >On 6/26/20 12:38 PM, Daniel Frey wrote: >> On 6/20/20 7:04 PM, William Kenworthy wrote: >>> Thanks for filing the bug. >> >> Gah! I forgot about this! >> >> I filed a bug now, I hope I made it clear enough. Others can pipe in >> there with comments if they like. >> >> I did indicate the two potential proposals to correct the issue in >the >> bug itself. >> >> https://bugs.gentoo.org/729752 >> >> Dan > >BEFORE I contribute to this bug, I'm posting here to see if others are >or have interest, in my thoughts on this issue and my related needs for > >extreme security, via Gentoo. Below is far from complete, but it only >provides a very snippets of my (secure) pathway forward with Gentoo. > >Interesting thread, thanks to all contributors. I'd like to add 'my >selfish' interest, as they also be espoused by other, more focused, >gentoo users. > >INTRO: > >I rarely build gentoo systems, for many reasons, that are not pretty >singularly focused. It drastically reduces security, performance and >upgrade issues. For me, the days of a any system, having groups or >users, are in the history books of very bad ideas. uP are so cheap and >less than $100, gets you a very 'bad ass' computer (Rasp. Pi 4+) 16 G >map-able ram. Furthermore, SOON, usb_4 devices are going to obsolete >the >entire concept of a 'hard drive'; hence the death (my prediction) of >groups and users on multi-USER systems, albeit slowly. > >Multi-function, Multi-tasking, and light weight, focused transient >clusters are the future. YMMV. > > >So solving a problem, that was real and big, decades ago, fails to look > >at the future. For me, Gentoo is future proof. I suggest a well >documented pathway forward; totally without the concept of groups and >users, on a typical, highly secure system. Which is now the baseline >for >real systems, particularly with a ipv4 or ipv6 static ip, that provide >focused and highly restricted functionalities. CA servers are going >private, as the public and root CA servers, are suspect, at best, as to > >being pristinely secure. Yes boys and girls most Certificate >Authorities >are HACK! Even the main root CAs. > >The F. Feds are the original culprits, but now it is a feeding frenzy. >The planet is now hacked, and groups and users concepts are the past. >imho! Danger Will Robinson Danger! > >So can some of the smarter (gentoo) folks illuminate how to totally >avoid groups and users, except for the minimum required, application >specific? For example like serial line tools, or outline a set of >tweaks/setting to avoid these altogether? > >I build embedded G. systems. I build single purpose G systems. I build >security G. systems (often with the ethernet, in only listen mode. I >build G. Firewalls. >I build G. highly restricted/filtered servers. NONE of those need users > >or groups. And if they do, I can obfuscate codes to provide that need, >to where filters and focused software gets what it needs to provide >functions. > >Yep, I'm moving to a total 'State_Machine_design' for critical >services. >Strip out every thing else. > >Am I alone, or have/are others contemplating such high secure pathways? > >I'd be fantastic to find a kernel hacker that is on the pathway of >extreme minimization too; private email is fine; if that is in your >wheel_house. > > >curiously alone?, >James James, Doesn't this imply that all the software and people interacting with the systems all have root-level access? One of the reasons MS systems were so vulnerable in the past was because they did not support seperated users. It's also still a problem with a lot of legacy systems. As long as more than 1 person can access the system, seperate users and groups/ACLs are necessary. Can you explain how having no users makes a system more secure? -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 6/26/20 12:38 PM, Daniel Frey wrote: On 6/20/20 7:04 PM, William Kenworthy wrote: Thanks for filing the bug. Gah! I forgot about this! I filed a bug now, I hope I made it clear enough. Others can pipe in there with comments if they like. I did indicate the two potential proposals to correct the issue in the bug itself. https://bugs.gentoo.org/729752 Dan BEFORE I contribute to this bug, I'm posting here to see if others are or have interest, in my thoughts on this issue and my related needs for extreme security, via Gentoo. Below is far from complete, but it only provides a very snippets of my (secure) pathway forward with Gentoo. Interesting thread, thanks to all contributors. I'd like to add 'my selfish' interest, as they also be espoused by other, more focused, gentoo users. INTRO: I rarely build gentoo systems, for many reasons, that are not pretty singularly focused. It drastically reduces security, performance and upgrade issues. For me, the days of a any system, having groups or users, are in the history books of very bad ideas. uP are so cheap and less than $100, gets you a very 'bad ass' computer (Rasp. Pi 4+) 16 G map-able ram. Furthermore, SOON, usb_4 devices are going to obsolete the entire concept of a 'hard drive'; hence the death (my prediction) of groups and users on multi-USER systems, albeit slowly. Multi-function, Multi-tasking, and light weight, focused transient clusters are the future. YMMV. So solving a problem, that was real and big, decades ago, fails to look at the future. For me, Gentoo is future proof. I suggest a well documented pathway forward; totally without the concept of groups and users, on a typical, highly secure system. Which is now the baseline for real systems, particularly with a ipv4 or ipv6 static ip, that provide focused and highly restricted functionalities. CA servers are going private, as the public and root CA servers, are suspect, at best, as to being pristinely secure. Yes boys and girls most Certificate Authorities are HACK! Even the main root CAs. The F. Feds are the original culprits, but now it is a feeding frenzy. The planet is now hacked, and groups and users concepts are the past. imho! Danger Will Robinson Danger! So can some of the smarter (gentoo) folks illuminate how to totally avoid groups and users, except for the minimum required, application specific? For example like serial line tools, or outline a set of tweaks/setting to avoid these altogether? I build embedded G. systems. I build single purpose G systems. I build security G. systems (often with the ethernet, in only listen mode. I build G. Firewalls. I build G. highly restricted/filtered servers. NONE of those need users or groups. And if they do, I can obfuscate codes to provide that need, to where filters and focused software gets what it needs to provide functions. Yep, I'm moving to a total 'State_Machine_design' for critical services. Strip out every thing else. Am I alone, or have/are others contemplating such high secure pathways? I'd be fantastic to find a kernel hacker that is on the pathway of extreme minimization too; private email is fine; if that is in your wheel_house. curiously alone?, James
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 6/20/20 7:04 PM, William Kenworthy wrote: Thanks for filing the bug. Gah! I forgot about this! I filed a bug now, I hope I made it clear enough. Others can pipe in there with comments if they like. I did indicate the two potential proposals to correct the issue in the bug itself. https://bugs.gentoo.org/729752 Dan
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On Sat, Jun 20, 2020 at 10:04 PM William Kenworthy wrote: > > I cant see any > advantage to having multiple ebuilds for a package instead of using a > support framework to deal with it other than exposing multiple > opportunities for things to go wrong and make it harder to fix. This not > an elegant design! Uh, refactoring shared code into modules is generally considered the best design. Generally packages are split up when they are shared, or when they have different update cycles or upstreams. The details around the splits vary between packages but if you cite and example it probably will be easy to explain why that particular example was split. KDE/Plasma was split up because it makes no sense to rebuild 500 binaries when one of them has a security update. Those account ebuilds were split out because multiple packages could require the same group, and this helps ensure the default uid/gid doesn't change depending on what order you install packages in. Packages like systemd/openrc tend to be a little more modular because they may require integration with other things and it doesn't make sense to replicate that integration across many versions of the packages on both sides. mysql-init-scripts is a separate package because it gets shared between mysql and mariadb. This isn't done often, but it does have the side benefit that if there is a bug in the init.d script you don't have to rebuild the whole database server to get a new bash script. You have virtual packages because sometimes you want to depend on a capability and not a specific package. For example you need an mta to be installed but you don't care which one it is, and so as a result you see virtuals show up in the install list even though they don't do anything. A fair bit of this comes from Gentoo's flexibility. If we didn't support 47 different ways of doing everything it would be much easier to create monolithic packages. In general we tend to find the balance. Plenty of other distros take this MUCH further than Gentoo does - though some of this is driven by being binary. The same source package works for any arch, but if you're doing a binary distro the manpages might work for everybody but obviously anything compiled has to be split up by arch. -- Rich
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 6/20/20 7:04 PM, William Kenworthy wrote: On 21/6/20 9:40 am, Daniel Frey wrote: On 6/20/20 6:21 PM, Rich Freeman wrote: On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey wrote: Maybe when I have a moment I'll file a bug. Dan Thanks for filing the bug. One of my pet peeves is that the last few years gentoo has been going down the path of spitting everything into smaller and smaller pieces and scattering them around - its fine when things work, but becomes a real pig to fault find and more often ends up in a call for help. I would really like packages to be self contained so its configuration and files are all in one place. I cant see any advantage to having multiple ebuilds for a package instead of using a support framework to deal with it other than exposing multiple opportunities for things to go wrong and make it harder to fix. This not an elegant design! BillK They were trying to solve the problem of having multiple packages dependent on a single user/group - mariadb/mysql comes to mind. By having these types of packages depend on something in the tree they can prevent the condition of having to remove the user/group when another package may still depend on it. It's kind of the opposite to the virtual/* packages I think, or maybe that's the beer talking. Dan
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 21/6/20 9:40 am, Daniel Frey wrote: > On 6/20/20 6:21 PM, Rich Freeman wrote: >> On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey wrote: > > Maybe when I have a moment I'll file a bug. > > Dan > Thanks for filing the bug. One of my pet peeves is that the last few years gentoo has been going down the path of spitting everything into smaller and smaller pieces and scattering them around - its fine when things work, but becomes a real pig to fault find and more often ends up in a call for help. I would really like packages to be self contained so its configuration and files are all in one place. I cant see any advantage to having multiple ebuilds for a package instead of using a support framework to deal with it other than exposing multiple opportunities for things to go wrong and make it harder to fix. This not an elegant design! BillK
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 6/20/20 6:21 PM, Rich Freeman wrote: On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey wrote: You just pointed out the ambiguity. Emerging a package solely by its name worked 99.9% of the time before this change. Now new users get the fun of "Gee, which one is the one I actually want?" MythTV is a fairly clear one to figure out, but other packages aren't. Honestly, your word of "ambiguity" was somewhat ambiguous. I had no idea what you were talking about in your original post. :) I think this is actually a fair criticism. Not so much that it isn't clear which one to install, but rather that this system does cause you to have to use full cat/pkg atoms when previous pkg alone would have worked. There have always been packages where this is necessary, but this has made this more common. Yes, I could've worded that better. I would imagine that if someone asks to install something like mythtv or asterisk there's a 0% chance that they want to install a package that creates a user or group, they want the actual package itself. I think that makes more sense. I've been using gentoo since 2003/04? and I've only had to use the cat/package expression maybe twice... and I believe those packages were python or perl related. It's more of a usability issue than anything. The way that it now deals with user and group creation is elegant, especially if you have more than one package that needs a specific user and/or group combination created. When I first saw portage spit out the ambiguity for the request `emerge mythtv` the first thing I thought was "Why would I need to merge a package to create a user? That's the package manager's problem..." :o) Maybe when I have a moment I'll file a bug. Dan
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey wrote: > > You just pointed out the ambiguity. > > Emerging a package solely by its name worked 99.9% of the time before > this change. > > Now new users get the fun of "Gee, which one is the one I actually > want?" MythTV is a fairly clear one to figure out, but other packages > aren't. Honestly, your word of "ambiguity" was somewhat ambiguous. I had no idea what you were talking about in your original post. :) I think this is actually a fair criticism. Not so much that it isn't clear which one to install, but rather that this system does cause you to have to use full cat/pkg atoms when previous pkg alone would have worked. There have always been packages where this is necessary, but this has made this more common. I don't think this was really something anybody thought of at the time - perhaps somebody might have suggested a tweak at the time if it had been. As others have pointed out you could just tweak portage to ignore the account category when expanding incomplete atoms to restore the previous behavior. In any case, as to why this system was devised just read: https://www.gentoo.org/glep/glep-0081.html It hasn't been communicated to users much because it tends to have little impact on them. Before packages just created accounts when needed. Now they pull in an account package that does it instead. If the user doesn't care to manage the uids/gids for various accounts they don't need to worry about how this works. If they do want to manage these themselves they can either create those accounts manually beforehand, or override these packages. It is also much more obvious when a new package is going to create additional accounts, so users who care about such things can intervene before merging the packages. Overall I'd say it is a net improvement. It of course led to a whole bunch of these packages being installed when the change was made, but these would generally be no-ops for existing users. -- Rich
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On Sunday, June 21, 2020 9:25:38 A.M. AEST Michael Orlitzky wrote: > On 2020-06-20 19:06, Daniel Frey wrote: > > I understand the dependencies problem that they were trying to solve, > > but I don't think the way it was implemented is a great one. > > This isn't a fundamental problem, it's your package manager being dumb. > File a bug; I can think of several band-aids for this, like adding a > flag to emerge that makes it prefer non-acct-* packages and then adding > that flag to EMERGE_DEFAULT_OPTS. Or do a quick check to see if any of the packages are dependencies of one of the other packages, and prefer the one highest on the ladder. -- Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/ Asking for technical help in newsgroups? Read this first: http://catb.org/~esr/faqs/smart-questions.html#intro
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
* Daniel Frey:
> You just pointed out the ambiguity.
I did no such thing, and there is no ambiguity. There is only the
failure to specify a package's identifier ("atom").
> Emerging a package solely by its name worked 99.9% of the time before
> this change.
Perhaps for the packages you used; I have obviously not verified
that. Even if it was the case, it was not guaranteed to work that
way. Package atoms are, and have been, of the form CATEGORY/NAME, not
just NAME. Emerge also expects atoms, not names (as do package.mask,
package.use, etc.).
> Now new users get the fun of "Gee, which one is the one I actually
> want?" MythTV is a fairly clear one to figure out, but other packages
> aren't.
"New users" can rely on Gentoo utilities like "eix", "emerge --search"
or "equery". There's also https://packages.gentoo.org . Thus, I see no
problem.
-Ralph
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 2020-06-20 19:06, Daniel Frey wrote: > > I understand the dependencies problem that they were trying to solve, > but I don't think the way it was implemented is a great one. > This isn't a fundamental problem, it's your package manager being dumb. File a bug; I can think of several band-aids for this, like adding a flag to emerge that makes it prefer non-acct-* packages and then adding that flag to EMERGE_DEFAULT_OPTS.
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 6/20/20 11:56 AM, Ralph Seichter wrote: * Daniel Frey: I went to emerge mythtv (I think) and now it says it's an ambiguous requests with *both* the group and user of the same name. You need to emerge "media-tv/mythtv", not just "mythtv". Nothing ambiguous about it. Further reading: https://www.gentoo.org/glep/glep-0081.html -Ralph You just pointed out the ambiguity. Emerging a package solely by its name worked 99.9% of the time before this change. Now new users get the fun of "Gee, which one is the one I actually want?" MythTV is a fairly clear one to figure out, but other packages aren't. I understand the dependencies problem that they were trying to solve, but I don't think the way it was implemented is a great one. Dan
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
* Daniel Frey: > I went to emerge mythtv (I think) and now it says it's an ambiguous > requests with *both* the group and user of the same name. You need to emerge "media-tv/mythtv", not just "mythtv". Nothing ambiguous about it. Further reading: https://www.gentoo.org/glep/glep-0081.html -Ralph
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
On 6/19/20 9:04 PM, Walter Dnes wrote: Inquiring minds want to know. What exactly do they accomplish, besides cluttering up a database somewhere? It's not the cluttering of databases that bother me, it's the creation of many ambiguous requests now. I went to emerge mythtv (I think) and now it says it's an ambiguous requests with *both* the group and user of the same name. I must say I'm baffled that a proposal that would create so many ambiguous requests passed... Dan
RE: [gentoo-user] What's with all these "acct-group" ebuilds recently?
How do unsubscrip from all Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Walter Dnes<mailto:waltd...@waltdnes.org> Sent: Saturday, June 20, 2020 12:05 AM To: Gentoo Users List<mailto:gentoo-user@lists.gentoo.org> Subject: [gentoo-user] What's with all these "acct-group" ebuilds recently? Inquiring minds want to know. What exactly do they accomplish, besides cluttering up a database somewhere? -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?
Walter Dnes wrote: > Inquiring minds want to know. What exactly do they accomplish, > besides cluttering up a database somewhere? > I found this: https://wiki.gentoo.org/wiki/Categories_acct-group_and_acct-user Dale :-) :-)
[gentoo-user] What's with all these "acct-group" ebuilds recently?
Inquiring minds want to know. What exactly do they accomplish, besides cluttering up a database somewhere? -- Walter Dnes I don't run "desktop environments"; I run useful applications
