"One could easily poke holes in this complaint; the characterization of PAM as "modern" is somewhat amusing; it is 1990s technology."
Dafuk. If he's going to nitpick, then so am I. Marc did not say PAM was modern. He mentioned a modern Linux distro with pulseaudio, pam and systemd - to infer that he therefore considers PAM to be modern is a straw man argument at best. "in the early 1990s, BSD-oriented developers were equally unconcerned about the difficulty of porting their code to Linux." In the early 1990s, Linux was a dinky little toy, far from the ubiquitous platform it has become. The straw man rears its grassy head again. At least he recognises that a Linux monoculture would be just as damaging as the current arrangement. On Sat, Nov 17, 2012 at 7:57 PM, Andres Perera <andre...@zoho.com> wrote: > On Sat, Nov 17, 2012 at 3:20 AM, Eric Furman <ericfur...@fastmail.net> wrote: >> You missed the point. >> This is a joke. >> Rod was making a joke by pointing out how F****** retarded these people >> are. > > i'm going to pretend that you pointed out that cgroups prevent > double-forking from being a factor whereas pgroups do not > > this is a question of policy, not api: > > 1. if a program double-forks, that program has made it clear that it > does not need the destructors scripted in "systemd implementation", > and is eligible for being terminated by the generic, all-encompasing, > sysv killall(), linux killall5, or bsd kill(-1) at the end of > shutdown. this conclusion is drawn by the fact that the program can > negate scripted destructors ANYWAY under cgroups by way of being > unrestricted in its set of system calls (which is a concern OUTSIDE > "systemd implementation", therefore the role of a more generic > utility), or by plain bat shit insane userland code. there's no > sandbox being added by cgroups here > > 2. if a program double-forks, security is not compromised because the > permissions of that program are completely orthogonal to control via > "systemd implementation". the admin's *policy* is that there's always > an interest in running certain daemons as certain users. that "systemd > implementation" can also map processes to users is coincidental > > therefore the requirement for cgroups is completely arbitrary > > also of interest: > > * early versions of systemd documentation advised daemon authors not > to double fork. presumably cgroups wasn't in the radar at the time > > * several (all?) openbsd daemons have options for not double-forking. > some of these daemons have the gall of preceding systemd > >> >> On Sat, Nov 17, 2012, at 02:21 AM, Andres Perera wrote: >>> On Sat, Nov 17, 2012 at 1:55 AM, Rod Whitworth <glis...@witworx.com> >>> wrote: >>> > On Fri, 16 Nov 2012 20:49:37 -0600, Amit Kulkarni wrote: >>> > >>> >>https://lwn.net/Articles/524606/ >>> >> >>> >>don't have a subscription but for those who do, enjoy. >>> >> >>> > >>> > But http://lwn.net/Articles/524920/ will give you the idea without $$$ >>> >>> "rleigh, it's really not as easy as you think. Making the event loop >>> portable to kqueue is complex, but doable, I can agree to that. -- But >>> the trouble starts beyond that. The BSDs don't have anything like >>> cgroups. *There's no way to attach a name to a group of processes, in >>> a hierarchal, secure way*. And you cannot emulate this. (And no, don't >>> say "BSD jail" now, because that is something very different). But >>> this already is at the very core of systemd. It's how systemd tracks >>> services." >>> >>> how can someone write this and not explain why a process managing >>> pgroups can't achieve the same results? >>> >>> pgroups is going to be the first alternative for someone instinctively >>> looking for a portable alternative, so i'm genuinely interested in >>> knowing why they've discarded the idea >>> >>> i am, however, aware of differences *unrelated* to writing a systemd >>> like appliance. pgroups do not provide per item hostname and other >>> virtualization facilities in freebsd jails/linux cgroups, but what >>> about *relevant* differences? something weak like "the index for for >>> cgroups is wide enough to fit an UUID"? in other words, something that >>> *doesn't* require a completely new api? > -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
