Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #189609 > unrolled thread
| Started by | Urs Thuermann <urs@isnogud.escape.de> |
|---|---|
| First post | 2017-12-06 23:20 +0100 |
| Last post | 2017-12-07 08:50 +0100 |
| Articles | 20 on this page of 127 — 38 participants |
Back to article view | Back to linux.debian.user
Embarrassing security bug in systemd Urs Thuermann <urs@isnogud.escape.de> - 2017-12-06 23:20 +0100
Re: Embarrassing security bug in systemd Roberto C. Sánchez <roberto@debian.org> - 2017-12-06 23:50 +0100
Re: Embarrassing security bug in systemd Ben Caradoc-Davies <ben@transient.nz> - 2017-12-07 00:40 +0100
Re: Embarrassing security bug in systemd Roberto C. Sánchez <roberto@debian.org> - 2017-12-07 03:50 +0100
Re: Embarrassing security bug in systemd deloptes <deloptes@gmail.com> - 2017-12-07 07:30 +0100
Re: Embarrassing security bug in systemd Ben Caradoc-Davies <ben@transient.nz> - 2017-12-06 23:50 +0100
Re: Embarrassing security bug in systemd Dave Sherohman <dave@sherohman.org> - 2017-12-07 10:40 +0100
Re: Embarrassing security bug in systemd Tixy <tixy@yxit.co.uk> - 2017-12-07 11:30 +0100
Re: Embarrassing security bug in systemd Jonathan Dowland <jmtd@debian.org> - 2017-12-07 11:50 +0100
Re: Embarrassing security bug in systemd Jimmy Johnson <field.engineer@gmail.com> - 2017-12-09 03:50 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-09 17:50 +0100
Re: Embarrassing security bug in systemd Jimmy Johnson <field.engineer@gmail.com> - 2017-12-10 10:00 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-10 20:40 +0100
Re: Embarrassing security bug in systemd <tomas@tuxteam.de> - 2017-12-07 11:40 +0100
Re: Embarrassing security bug in systemd Roberto C. Sánchez <roberto@debian.org> - 2017-12-07 16:00 +0100
Re: Embarrassing security bug in systemd Michael Biebl <biebl@debian.org> - 2017-12-07 20:30 +0100
Re: Embarrassing security bug in systemd <tomas@tuxteam.de> - 2017-12-08 09:20 +0100
Re: Embarrassing security bug in systemd deloptes <deloptes@gmail.com> - 2017-12-08 12:40 +0100
Re: Embarrassing security bug in systemd <tomas@tuxteam.de> - 2017-12-08 13:40 +0100
Re: Embarrassing security bug in systemd deloptes <deloptes@gmail.com> - 2017-12-08 21:40 +0100
Re: Embarrassing security bug in systemd Jonathan Dowland <jmtd@debian.org> - 2017-12-08 17:10 +0100
Re: Embarrassing security bug in systemd Curt <curty@free.fr> - 2017-12-08 19:10 +0100
Re: Embarrassing security bug in systemd Menelaos Maglis <mmaglis@metacom.gr> - 2017-12-08 19:40 +0100
Re: Embarrassing security bug in systemd Menelaos Maglis <mmaglis@metacom.gr> - 2017-12-08 19:50 +0100
Re: Embarrassing security bug in systemd Jonathan Dowland <jmtd@debian.org> - 2017-12-08 20:50 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-08 21:20 +0100
Re: Embarrassing security bug in systemd Jonathan Dowland <jmtd@debian.org> - 2017-12-09 09:10 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-09 11:20 +0100
Re: Embarrassing security bug in systemd Jonathan Dowland <jmtd@debian.org> - 2017-12-09 19:40 +0100
Re: Embarrassing security bug in systemd Dejan Jocic <jodejka@gmail.com> - 2017-12-09 20:30 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-09 22:00 +0100
Re: Embarrassing security bug in systemd Dejan Jocic <jodejka@gmail.com> - 2017-12-10 00:40 +0100
Re: Embarrassing security bug in systemd Joe <joe@jretrading.com> - 2017-12-10 10:40 +0100
Re: Embarrassing security bug in systemd Dejan Jocic <jodejka@gmail.com> - 2017-12-10 11:20 +0100
Re: Embarrassing security bug in systemd Joe <joe@jretrading.com> - 2017-12-10 12:40 +0100
Re: Embarrassing security bug in systemd Dejan Jocic <jodejka@gmail.com> - 2017-12-10 16:10 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-11 15:10 +0100
Re: Embarrassing security bug in systemd Roberto C. Sánchez <roberto@debian.org> - 2017-12-09 21:10 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-09 21:10 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-08 21:50 +0100
Re: Embarrassing security bug in systemd John Hasler <jhasler@newsguy.com> - 2017-12-08 22:30 +0100
Re: Embarrassing security bug in systemd Glenn English <ghe2001@gmail.com> - 2017-12-09 02:50 +0100
Re: Embarrassing security bug in systemd John Hasler <jhasler@newsguy.com> - 2017-12-09 06:50 +0100
Re: Embarrassing security bug in systemd Jonathan Dowland <jmtd@debian.org> - 2017-12-09 09:20 +0100
Re: Embarrassing security bug in systemd Jonathan Dowland <jmtd@debian.org> - 2017-12-09 09:10 +0100
Re: Embarrassing security bug in systemd Christian Seiler <christian@iwakd.de> - 2017-12-15 13:30 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-15 14:10 +0100
Re: Embarrassing security bug in systemd John Hasler <jhasler@newsguy.com> - 2017-12-15 16:00 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-08 21:50 +0100
Re: Embarrassing security bug in systemd <tomas@tuxteam.de> - 2017-12-08 22:40 +0100
Re: Embarrassing security bug in systemd John Hasler <jhasler@newsguy.com> - 2017-12-09 00:30 +0100
Re: Embarrassing security bug in systemd <tomas@tuxteam.de> - 2017-12-09 10:00 +0100
Re: Embarrassing security bug in systemd Dave Sherohman <dave@sherohman.org> - 2017-12-08 10:00 +0100
Re: Embarrassing security bug in systemd Cindy-Sue Causey <butterflybytes@gmail.com> - 2017-12-08 23:40 +0100
Re: Embarrassing security bug in systemd Joe <joe@jretrading.com> - 2017-12-09 00:30 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-09 01:20 +0100
Re: Embarrassing security bug in systemd Joe <joe@jretrading.com> - 2017-12-09 11:40 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-09 15:30 +0100
Re: Embarrassing security bug in systemd The Wanderer <wanderer@fastmail.fm> - 2017-12-10 01:00 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-10 22:20 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-09 17:50 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-09 18:20 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-09 21:20 +0100
Re: Embarrassing security bug in systemd <tomas@tuxteam.de> - 2017-12-10 12:00 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-10 17:10 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-10 20:40 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-10 21:30 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-10 23:10 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-11 00:10 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-11 00:50 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-11 12:30 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-11 13:40 +0100
Re: Embarrassing security bug in systemd <tomas@tuxteam.de> - 2017-12-11 14:40 +0100
Re: Embarrassing security bug in systemd <tomas@tuxteam.de> - 2017-12-10 21:50 +0100
Re: Embarrassing security bug in systemd Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2017-12-11 13:00 +0100
Re: Embarrassing security bug in systemd <tomas@tuxteam.de> - 2017-12-11 13:40 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-11 16:30 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-10 23:10 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-11 01:30 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-11 04:40 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-11 06:10 +0100
Re: Embarrassing security bug in systemd Gene Heskett <gheskett@shentel.net> - 2017-12-11 07:40 +0100
Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd) rhkramer@gmail.com - 2017-12-11 15:40 +0100
Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd) Darac Marjal <mailinglist@darac.org.uk> - 2017-12-11 16:00 +0100
Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd) rhkramer@gmail.com - 2017-12-11 18:30 +0100
Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd) Joe <joe@jretrading.com> - 2017-12-11 16:30 +0100
Re: Rust? (and a wordsmithing question) "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2017-12-11 17:40 +0100
Re: Rust? (and a wordsmithing question) David Wright <deblis@lionunicorn.co.uk> - 2017-12-11 20:10 +0100
Re: Rust? (and a wordsmithing question) <tomas@tuxteam.de> - 2017-12-12 09:30 +0100
Re: Rust? (and a wordsmithing question) "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2017-12-12 17:30 +0100
Re: Rust? (and a wordsmithing question) <tomas@tuxteam.de> - 2017-12-12 17:50 +0100
Re: Rust? (and a wordsmithing question) Curt <curty@free.fr> - 2017-12-12 18:20 +0100
Re: Rust? (and a wordsmithing question) Richard Hector <richard@walnut.gen.nz> - 2017-12-13 04:40 +0100
Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd) rhkramer@gmail.com - 2017-12-11 18:30 +0100
Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd) David Wright <deblis@lionunicorn.co.uk> - 2017-12-12 19:10 +0100
UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd) Jason <electron@emypeople.net> - 2018-01-09 05:10 +0100
Re: UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd) Christian Groessler <chris@groessler.org> - 2018-01-09 16:00 +0100
Re: UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd) Roberto C. Sánchez <roberto@debian.org> - 2018-01-09 16:30 +0100
Re: UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd) Christian Groessler <chris@groessler.org> - 2018-01-09 18:10 +0100
Re: UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd) Erik Christiansen <dvalin@internode.on.net> - 2018-01-10 04:50 +0100
Re: Embarrassing security bug in systemd Menelaos Maglis <mmaglis@metacom.gr> - 2017-12-09 01:40 +0100
Re: Embarrassing security bug in systemd Mark Fletcher <mark27q1@gmail.com> - 2017-12-09 03:10 +0100
Re: Embarrassing security bug in systemd Joe <joe@jretrading.com> - 2017-12-09 10:50 +0100
Re: Embarrassing security bug in systemd Ric Moore <wayward4now@gmail.com> - 2017-12-09 16:40 +0100
Re: Embarrassing security bug in systemd Tom Furie <tom@furie.org.uk> - 2017-12-09 17:10 +0100
Re: Embarrassing security bug in systemd Ben Caradoc-Davies <ben@transient.nz> - 2017-12-09 22:10 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-09 18:20 +0100
Re: Embarrassing security bug in systemd Michael Stone <mstone@debian.org> - 2017-12-07 00:00 +0100
Re: Embarrassing security bug in systemd Joe <joe@jretrading.com> - 2017-12-07 09:40 +0100
Re: Embarrassing security bug in systemd Glenn English <ghe2001@gmail.com> - 2017-12-07 00:10 +0100
Re: Embarrassing security bug in systemd Brian <ad44@cityscape.co.uk> - 2017-12-07 00:10 +0100
Re: Embarrassing security bug in systemd Roberto C. Sánchez <roberto@debian.org> - 2017-12-07 03:50 +0100
Re: Embarrassing security bug in systemd Michael Lange <klappnase@freenet.de> - 2017-12-07 00:20 +0100
Re: Embarrassing security bug in systemd "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2017-12-07 00:50 +0100
Re: Embarrassing security bug in systemd Michael Stone <mstone@debian.org> - 2017-12-07 01:20 +0100
Re: Embarrassing security bug in systemd Roberto C. Sánchez <roberto@debian.org> - 2017-12-07 03:50 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-07 02:10 +0100
Re: Embarrassing security bug in systemd Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-12-07 03:40 +0100
Re: Embarrassing security bug in systemd Eric S Fraga <e.fraga@ucl.ac.uk> - 2017-12-07 08:30 +0100
Re: Embarrassing security bug in systemd Michael Biebl <biebl@debian.org> - 2017-12-07 00:50 +0100
Re: Embarrassing security bug in systemd Dejan Jocic <jodejka@gmail.com> - 2017-12-07 02:40 +0100
Re: Embarrassing security bug in systemd Menelaos Maglis <mmaglis@metacom.gr> - 2017-12-08 10:40 +0100
Re: Embarrassing security bug in systemd Roberto C. Sánchez <roberto@debian.org> - 2017-12-08 13:40 +0100
Re: Embarrassing security bug in systemd deloptes <deloptes@gmail.com> - 2017-12-08 20:10 +0100
Re: Embarrassing security bug in systemd David Wright <deblis@lionunicorn.co.uk> - 2017-12-07 01:10 +0100
Re: Embarrassing security bug in systemd Eric S Fraga <e.fraga@ucl.ac.uk> - 2017-12-07 08:30 +0100
Re: Embarrassing security bug in systemd David Baron <dbaron770@gmail.com> - 2017-12-07 08:50 +0100
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2017-12-08 17:10 +0100 |
| Message-ID | <uUtnP-6gP-5@gated-at.bofh.it> |
| In reply to | #189669 |
On Fri, 2017-12-08 at 12:17 +0100, deloptes wrote: > Michael Biebl wrote: > > > Basically, it was a completely inconsistent mess before systemd. > > Now you at least have a central place where you can configure your > > system behaviour. > > This is your opinion - if you can not understand the "mess" it is a > mess. > For most of us who dislike systemd your same statement is valid. I do > not > understand it and it is a mess. So we have 1:1 :) > Perhaps we like the old mess better than the new mess ;-) > > Please do not try to impose your opinion on others. Free software is > free > for this reason and we want to stay like this. We respect each others > opinion. I think you are allowing your dislike of systemd to cloud the truth of Michael's statement. In the past, we had *no consistency*: inittab had one thing, display managers another, ACPI scripts another...if you wanted a specific policy, you had to change three or more separate systems. Along came [a new system] which provided a single place to define a consistent policy. Now, you may not like [a new system] for any number of reasons, related or unrelated to this example. You may not like the default policy that is now applied using [a new system], but that does not change the essential truth of the previous paragraph. -- Jonathan Dowland
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2017-12-08 19:10 +0100 |
| Message-ID | <uUvfY-7su-9@gated-at.bofh.it> |
| In reply to | #189677 |
On 2017-12-08, Jonathan Dowland <jmtd@debian.org> wrote: > On Fri, 2017-12-08 at 12:17 +0100, deloptes wrote: >> Michael Biebl wrote: >> >> > Basically, it was a completely inconsistent mess before systemd. >> > Now you at least have a central place where you can configure your >> > system behaviour. >> >> This is your opinion - if you can not understand the "mess" it is a >> mess. >> For most of us who dislike systemd your same statement is valid. I do >> not >> understand it and it is a mess. So we have 1:1 :) >> Perhaps we like the old mess better than the new mess ;-) >> >> Please do not try to impose your opinion on others. Free software is >> free >> for this reason and we want to stay like this. We respect each others >> opinion. > > I think you are allowing your dislike of systemd to cloud the truth of > Michael's statement. > The OP was flameware. Nobody's embarrassed; there is no bug; nothing is "in systemd." There was a policy decision. Thus denuded of inflationary rhetoric the OP boils down to a parental guidance problem (joke). -- "The world is full of shipping clerks who have read the Harvard Classics." — Charles Bukowski
[toc] | [prev] | [next] | [standalone]
| From | Menelaos Maglis <mmaglis@metacom.gr> |
|---|---|
| Date | 2017-12-08 19:40 +0100 |
| Message-ID | <uUvJ0-7C8-1@gated-at.bofh.it> |
| In reply to | #189677 |
>> > Basically, it was a completely inconsistent mess before systemd. >> > Now you at least have a central place where you can configure your >> > system behaviour. > In the past, we had *no consistency*: inittab had one thing, display > managers another, ACPI scripts another...if you wanted a specific > policy, you had to change three or more separate systems. > > Along came [a new system] which provided a single place to define a > consistent policy. systemd provides a single place to define a consistent policy, provided your system uses systemd. > Now, you may not like [a new system] for any number of reasons, related > or unrelated to this example. You may not like the default policy that > is now applied using [a new system], but that does not change the > essential truth of the previous paragraph. Debian GNU/Linux offers alternative init systems, which people choose and use. They have their, often different, "default" settings. The Debian system does not impose a specific architecture. People often use the system's building blocks to build custom systems. In that case though, they also take on the responsibility to integrate them in the way they design the behavior of the system. If the conversation is restricted to a default installation using systemd, then I think the default policy could be different for laptop/desktop systems and for multi-user/server systems. It makes sense to me. In anycase, it should be a documented configuration option to allow for alternative use cases.
[toc] | [prev] | [next] | [standalone]
| From | Menelaos Maglis <mmaglis@metacom.gr> |
|---|---|
| Date | 2017-12-08 19:50 +0100 |
| Message-ID | <uUvSG-7Fy-7@gated-at.bofh.it> |
| In reply to | #189677 |
>> > Basically, it was a completely inconsistent mess before systemd. >> > Now you at least have a central place where you can configure your >> > system behaviour. > In the past, we had *no consistency*: inittab had one thing, display > managers another, ACPI scripts another...if you wanted a specific > policy, you had to change three or more separate systems. > > Along came [a new system] which provided a single place to define a > consistent policy. systemd provides a single place to define a consistent policy, provided your system uses systemd. > Now, you may not like [a new system] for any number of reasons, related > or unrelated to this example. You may not like the default policy that > is now applied using [a new system], but that does not change the > essential truth of the previous paragraph. Debian GNU/Linux offers alternative init systems, which people choose and use. They have their, often different, "default" settings. The Debian system does not impose a specific architecture. People often use the system's building blocks to build custom systems. In that case though, they also take on the responsibility to integrate them in the way they design the behavior of the system. If the conversation is restricted to a default installation using systemd, then I think the default policy could be different for laptop/desktop systems and for multi-user/server systems. It makes sense to me. In anycase, it should be a documented configuration option to allow for alternative use cases.
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2017-12-08 20:50 +0100 |
| Message-ID | <uUwOJ-8gM-11@gated-at.bofh.it> |
| In reply to | #189683 |
On Fri, Dec 08, 2017 at 07:09:06PM +0100, Menelaos Maglis wrote: >>> > Basically, it was a completely inconsistent mess before systemd. >>> > Now you at least have a central place where you can configure your >>> > system behaviour. >> In the past, we had *no consistency*: inittab had one thing, display >> managers another, ACPI scripts another...if you wanted a specific >> policy, you had to change three or more separate systems. >> >> Along came [a new system] which provided a single place to define a >> consistent policy. > >systemd provides a single place to define a consistent policy, provided >your system uses systemd. That's a good point. >Debian GNU/Linux offers alternative init systems, which people choose >and use. They have their, often different, "default" settings. It would perhaps be a good idea for the policy to be determined in an init-agnostic way.o >In anycase, it should be a documented configuration option to allow >for alternative use cases. No objection there, and I agree that the release notes should probably have covered the policy changes. That ship has now sailed unfortunately. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-12-08 21:20 +0100 |
| Message-ID | <uUxhL-kO-1@gated-at.bofh.it> |
| In reply to | #189688 |
On Fri 08 Dec 2017 at 19:26:41 +0000, Jonathan Dowland wrote: > On Fri, Dec 08, 2017 at 07:09:06PM +0100, Menelaos Maglis wrote: > > > > > Basically, it was a completely inconsistent mess before systemd. > > > > > Now you at least have a central place where you can configure your > > > > > system behaviour. > > > In the past, we had *no consistency*: inittab had one thing, display > > > managers another, ACPI scripts another...if you wanted a specific > > > policy, you had to change three or more separate systems. > > > > > > Along came [a new system] which provided a single place to define a > > > consistent policy. > > > > systemd provides a single place to define a consistent policy, provided > > your system uses systemd. > > That's a good point. Not really. systemd doesn't stop providing a single place to define a consistent policy because a set of users do not use it. > > > Debian GNU/Linux offers alternative init systems, which people choose > > and use. They have their, often different, "default" settings. > > It would perhaps be a good idea for the policy to be determined in an > init-agnostic way.o > > > In anycase, it should be a documented configuration option to allow > > for alternative use cases. > > No objection there, and I agree that the release notes should probably > have covered the policy changes. That ship has now sailed unfortunately. A bug report against the release notes with a patch is always worth a try. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2017-12-09 09:10 +0100 |
| Message-ID | <uUImR-7D2-5@gated-at.bofh.it> |
| In reply to | #189689 |
On Fri, Dec 08, 2017 at 07:57:03PM +0000, Brian wrote: >> That's a good point. > >Not really. systemd doesn't stop providing a single place to define a >consistent policy because a set of users do not use it. That's not the point I thought was good: the point is, in Debian, systemd is optional. As an Operating System, consistency is a good thing, and so if we have a consistent policy for anything, it would be nice if that was not dependent on optional software. On the other hand, nobody has put together an alternative to achieve the same thing, and we are all volunteers. >A bug report against the release notes with a patch is always worth a >try. The relevant release notes would be the ones for the release that introduced systemd which has been and gone. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-12-09 11:20 +0100 |
| Message-ID | <uUKoF-mw-15@gated-at.bofh.it> |
| In reply to | #189708 |
On Sat 09 Dec 2017 at 07:52:56 +0000, Jonathan Dowland wrote: > On Fri, Dec 08, 2017 at 07:57:03PM +0000, Brian wrote: > > > That's a good point. > > > > Not really. systemd doesn't stop providing a single place to define a > > consistent policy because a set of users do not use it. > > That's not the point I thought was good: the point is, in Debian, > systemd is optional. As an Operating System, consistency is a good > thing, and so if we have a consistent policy for anything, it would be > nice if that was not dependent on optional software. On the other hand, > nobody has put together an alternative to achieve the same thing, and we > are all volunteers. Consistencey can be achieved by not installing policykit. The OP appears to have chosen the wrong target. > > A bug report against the release notes with a patch is always worth a > > try. > > The relevant release notes would be the ones for the release that > introduced systemd which has been and gone. Nothing is irreversible. A proposed erratum, then. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2017-12-09 19:40 +0100 |
| Message-ID | <uUScx-5ew-1@gated-at.bofh.it> |
| In reply to | #189713 |
On Sat, 2017-12-09 at 10:00 +0000, Brian wrote: > Consistencey can be achieved by not installing policykit. The OP > appears to have chosen the wrong target.Consistencey can be achieved > by not installing policykit. As Michael pointed out in [1], that's not the case; prior to polkit, there was no consistency. [1] <8430b277-3757-8261-0e1e-23e274a0b49a@debian.org>
[toc] | [prev] | [next] | [standalone]
| From | Dejan Jocic <jodejka@gmail.com> |
|---|---|
| Date | 2017-12-09 20:30 +0100 |
| Message-ID | <uUSYW-5Q5-5@gated-at.bofh.it> |
| In reply to | #189729 |
On 09-12-17, Jonathan Dowland wrote: > On Sat, 2017-12-09 at 10:00 +0000, Brian wrote: > > Consistencey can be achieved by not installing policykit. The OP > > appears to have chosen the wrong target.Consistencey can be achieved > by not installing policykit. > > As Michael pointed out in [1], that's not the case; prior to polkit, > there was no consistency. > > > [1] <8430b277-3757-8261-0e1e-23e274a0b49a@debian.org> > Is it anywhere in Debian documentation described how to achieve consistency in a way different than current defaults? Or, even better, is there way that we could get some kind of configuration option to achieve it? Polkit does not really have user friendly configuration and is not really something that system administrators configure on a everyday bases. At least not in my experience. Only thing that I did find about configuring polkit was from some other distros. Debian wiki page about PolicyKit is not really helpful. Thank you for your time, Dejan
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-12-09 22:00 +0100 |
| Message-ID | <uUUo1-6zq-1@gated-at.bofh.it> |
| In reply to | #189730 |
On Sat 09 Dec 2017 at 20:07:17 +0100, Dejan Jocic wrote: > On 09-12-17, Jonathan Dowland wrote: > > On Sat, 2017-12-09 at 10:00 +0000, Brian wrote: > > > Consistencey can be achieved by not installing policykit. The OP > > > appears to have chosen the wrong target.Consistencey can be achieved > by not installing policykit. > > > > As Michael pointed out in [1], that's not the case; prior to polkit, > > there was no consistency. > > > > > > [1] <8430b277-3757-8261-0e1e-23e274a0b49a@debian.org> > > > > Is it anywhere in Debian documentation described how to achieve > consistency in a way different than current defaults? Or, even better, > is there way that we could get some kind of configuration option to > achieve it? Polkit does not really have user friendly configuration and > is not really something that system administrators configure on a > everyday bases. At least not in my experience. Only thing that I did > find about configuring polkit was from some other distros. Debian wiki > page about PolicyKit is not really helpful. Apart from not installing policykit, setting allow_active to "no" in /usr/share/polkit-1/actions/org.freedesktop.login1.policy would do it. Much better is to use /etc/polkit-1/localauthority. See the manual for pklocalauthority. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Dejan Jocic <jodejka@gmail.com> |
|---|---|
| Date | 2017-12-10 00:40 +0100 |
| Message-ID | <uUWSS-8fe-13@gated-at.bofh.it> |
| In reply to | #189735 |
On 09-12-17, Brian wrote:
> On Sat 09 Dec 2017 at 20:07:17 +0100, Dejan Jocic wrote:
>
> > On 09-12-17, Jonathan Dowland wrote:
> > > On Sat, 2017-12-09 at 10:00 +0000, Brian wrote:
> > > > Consistencey can be achieved by not installing policykit. The OP
> > > > appears to have chosen the wrong target.Consistencey can be achieved > by not installing policykit.
> > >
> > > As Michael pointed out in [1], that's not the case; prior to polkit,
> > > there was no consistency.
> > >
> > >
> > > [1] <8430b277-3757-8261-0e1e-23e274a0b49a@debian.org>
> > >
> >
> > Is it anywhere in Debian documentation described how to achieve
> > consistency in a way different than current defaults? Or, even better,
> > is there way that we could get some kind of configuration option to
> > achieve it? Polkit does not really have user friendly configuration and
> > is not really something that system administrators configure on a
> > everyday bases. At least not in my experience. Only thing that I did
> > find about configuring polkit was from some other distros. Debian wiki
> > page about PolicyKit is not really helpful.
>
> Apart from not installing policykit, setting allow_active to "no" in
> /usr/share/polkit-1/actions/org.freedesktop.login1.policy would do it.
>
> Much better is to use /etc/polkit-1/localauthority. See the manual for
> pklocalauthority.
>
> --
> Brian.
>
Man page for pklocalauthority is bit more helpful, but far from self
explanatory. In its examples section, it provides some insight about
writing .pkla files, but it does not show all possible options, or at
least I can't be sure that it does. For example:
[Exclude Some Problematic Users]
Identity=unix-user:homer;unix-user:grimes
Action=com.example.awesomeproduct.*
ResultAny=no
ResultInactive=no
ResultActive=auth_admin
According to that, and after reading man page for polkit, I can only
deduct that .pkla file will for that example in that
com.example.awesomeproduct.* files reads lines under defaults and
"answer" on allow_any and allow_inactive with no value and on
allow_active with auth_admin value. Fine, that can work. Guess that you
can use wildecards for all users, like unix-user:*, but that is only
guess, cause I can't see it documented anywhere ( might have missed it).
What I also do not see anywhere is if those are the only options
available? Or there is some man page, or additional documentation in
Debian that can explain that?
Thank you for your time,
Dejan
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2017-12-10 10:40 +0100 |
| Message-ID | <uV6fw-5TZ-9@gated-at.bofh.it> |
| In reply to | #189737 |
On Sun, 10 Dec 2017 00:13:59 +0100 Dejan Jocic <jodejka@gmail.com> wrote: > > Man page for pklocalauthority is bit more helpful, but far from self > explanatory. And not updated for Debian. > In its examples section, it provides some insight about > writing .pkla files, but it does not show all possible options, or at > least I can't be sure that it does. For example: > > [Exclude Some Problematic Users] > Identity=unix-user:homer;unix-user:grimes > Action=com.example.awesomeproduct.* > ResultAny=no > ResultInactive=no > ResultActive=auth_admin > > According to that, and after reading man page for polkit, I can only > deduct that .pkla file will for that example in that > com.example.awesomeproduct.* files reads lines under defaults and > "answer" on allow_any and allow_inactive with no value and on > allow_active with auth_admin value. Fine, that can work. Guess that > you can use wildecards for all users, like unix-user:*, but that is > only guess, cause I can't see it documented anywhere ( might have > missed it). What I also do not see anywhere is if those are the only > options available? Or there is some man page, or additional > documentation in Debian that can explain that? > More examples, and in fact, all the Debian policies, are *.policy files and under /usr/share/polkit-1, as Brian pointed out. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Dejan Jocic <jodejka@gmail.com> |
|---|---|
| Date | 2017-12-10 11:20 +0100 |
| Message-ID | <uV6Se-6nS-9@gated-at.bofh.it> |
| In reply to | #189744 |
On 10-12-17, Joe wrote: > On Sun, 10 Dec 2017 00:13:59 +0100 > Dejan Jocic <jodejka@gmail.com> wrote: > > > > > > Man page for pklocalauthority is bit more helpful, but far from self > > explanatory. > > And not updated for Debian. > > > In its examples section, it provides some insight about > > writing .pkla files, but it does not show all possible options, or at > > least I can't be sure that it does. For example: > > > > [Exclude Some Problematic Users] > > Identity=unix-user:homer;unix-user:grimes > > Action=com.example.awesomeproduct.* > > ResultAny=no > > ResultInactive=no > > ResultActive=auth_admin > > > > According to that, and after reading man page for polkit, I can only > > deduct that .pkla file will for that example in that > > com.example.awesomeproduct.* files reads lines under defaults and > > "answer" on allow_any and allow_inactive with no value and on > > allow_active with auth_admin value. Fine, that can work. Guess that > > you can use wildecards for all users, like unix-user:*, but that is > > only guess, cause I can't see it documented anywhere ( might have > > missed it). What I also do not see anywhere is if those are the only > > options available? Or there is some man page, or additional > > documentation in Debian that can explain that? > > > More examples, and in fact, all the Debian policies, are *.policy > files and under /usr/share/polkit-1, as Brian pointed out. > > -- > Joe > And all the files under /usr/share/polkiit-1 should listen to the local settings under /etc/polkit-1/localauthority/ so I do not understand what is your point? Thank you for your time, Dejan Or the man pages are totally wrong?
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2017-12-10 12:40 +0100 |
| Message-ID | <uV87E-73G-3@gated-at.bofh.it> |
| In reply to | #189746 |
On Sun, 10 Dec 2017 11:02:45 +0100 Dejan Jocic <jodejka@gmail.com> wrote: > On 10-12-17, Joe wrote: > > On Sun, 10 Dec 2017 00:13:59 +0100 > > Dejan Jocic <jodejka@gmail.com> wrote: > > > > > > > > > > Man page for pklocalauthority is bit more helpful, but far from > > > self explanatory. > > > > And not updated for Debian. > > > > > In its examples section, it provides some insight about > > > writing .pkla files, but it does not show all possible options, > > > or at least I can't be sure that it does. For example: > > > > > > [Exclude Some Problematic Users] > > > Identity=unix-user:homer;unix-user:grimes > > > Action=com.example.awesomeproduct.* > > > ResultAny=no > > > ResultInactive=no > > > ResultActive=auth_admin > > > > > > According to that, and after reading man page for polkit, I can > > > only deduct that .pkla file will for that example in that > > > com.example.awesomeproduct.* files reads lines under defaults and > > > "answer" on allow_any and allow_inactive with no value and on > > > allow_active with auth_admin value. Fine, that can work. Guess > > > that you can use wildecards for all users, like unix-user:*, but > > > that is only guess, cause I can't see it documented anywhere > > > ( might have missed it). What I also do not see anywhere is if > > > those are the only options available? Or there is some man page, > > > or additional documentation in Debian that can explain that? > > > > > More examples, and in fact, all the Debian policies, are *.policy > > files and under /usr/share/polkit-1, as Brian pointed out. > > > > -- > > Joe > > > > And all the files under /usr/share/polkiit-1 should listen to the > local settings under /etc/polkit-1/localauthority/ so I do not > understand what is your point? I thought you might find more examples helpful. The man page says that policies come from /etc/polkit-1 and /var/lib/polkit-1, but on my system the /var/lib location is almost empty, and there's a lot in /usr/share/polkit-1, almost nothing in /etc/polkit-1. > > Or the man pages are totally wrong? > Man pages are almost never totally wrong. Wrong in small but critical details, yes, often. There's some stuff about polkit on the Net, but nothing much official apart from the man pages, as far as I can see. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Dejan Jocic <jodejka@gmail.com> |
|---|---|
| Date | 2017-12-10 16:10 +0100 |
| Message-ID | <uVboS-P9-19@gated-at.bofh.it> |
| In reply to | #189749 |
On 10-12-17, Joe wrote: > On Sun, 10 Dec 2017 11:02:45 +0100 > Dejan Jocic <jodejka@gmail.com> wrote: > > > On 10-12-17, Joe wrote: > > > On Sun, 10 Dec 2017 00:13:59 +0100 > > > Dejan Jocic <jodejka@gmail.com> wrote: > > > > > > > > > > > > > > Man page for pklocalauthority is bit more helpful, but far from > > > > self explanatory. > > > > > > And not updated for Debian. > > > > > > > In its examples section, it provides some insight about > > > > writing .pkla files, but it does not show all possible options, > > > > or at least I can't be sure that it does. For example: > > > > > > > > [Exclude Some Problematic Users] > > > > Identity=unix-user:homer;unix-user:grimes > > > > Action=com.example.awesomeproduct.* > > > > ResultAny=no > > > > ResultInactive=no > > > > ResultActive=auth_admin > > > > > > > > According to that, and after reading man page for polkit, I can > > > > only deduct that .pkla file will for that example in that > > > > com.example.awesomeproduct.* files reads lines under defaults and > > > > "answer" on allow_any and allow_inactive with no value and on > > > > allow_active with auth_admin value. Fine, that can work. Guess > > > > that you can use wildecards for all users, like unix-user:*, but > > > > that is only guess, cause I can't see it documented anywhere > > > > ( might have missed it). What I also do not see anywhere is if > > > > those are the only options available? Or there is some man page, > > > > or additional documentation in Debian that can explain that? > > > > > > > More examples, and in fact, all the Debian policies, are *.policy > > > files and under /usr/share/polkit-1, as Brian pointed out. > > > > > > -- > > > Joe > > > > > > > And all the files under /usr/share/polkiit-1 should listen to the > > local settings under /etc/polkit-1/localauthority/ so I do not > > understand what is your point? > > I thought you might find more examples helpful. The man page says that > policies come from /etc/polkit-1 and /var/lib/polkit-1, but on my > system the /var/lib location is almost empty, and there's a lot > in /usr/share/polkit-1, almost nothing in /etc/polkit-1. > And, like I've said, thank you for your time. But those examples are all policy files and local settings are done under /etc/polkit-1/localauthority.conf.d/ for configuring which users, groups or netgroups will be considered as admins for authentication, and under /etc/polkit-1/localauthority/ directories with .pkla extension files should be used for overriding policies with local settings. At least it goes like that as far as I could deduct from man pages ( anyone thinking that I did not understood that well, please correct me ). Now, files under /etc/polkit-1/localauthority.conf.d/ I understand, or at least believe so. What I'm still searching for is better understanding of those .pkla files. I've read those man pages some time ago, when I've started with attempts to wrap my head around policikit, but was rather busy after that and did not completely finish with it. If I understood it right, about any .pkla file should look something like this: [ Description of what it does ] Identity=unix-user:someuser;unix-user:someotheruser;unix-group:somegroup;unix-group:someothergroup;unix-netgroup:somegroup;unix-netgroup:someothergroup Action=something.from.usr.share.polkit-1.actions ResultAny=no/yes/auth_self/auth_admin/auth_self_keep/auth_admin_keep ResultInactivee=same/options/as/above ResultActive=same/options/as/above Now, what I believe is that for Identity and Action wildecards are allowed and that there are no more options aside from ResultAny, ResultInactive and ResultActive that can follow Action part. And that no, yes or other values will be returned to Defaults section in that policy file defined under Action part and change whatever was defined there. If someone with greater understanding of Polkit could tell me if I got it right, or not, that would be great. In case that I did not get that right, any point in right direction, or explanation would be great too. Thank you for your time, Dejan
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-12-11 15:10 +0100 |
| Message-ID | <uVwWm-6eX-11@gated-at.bofh.it> |
| In reply to | #189756 |
On Sun 10 Dec 2017 at 15:52:30 +0100, Dejan Jocic wrote: > On 10-12-17, Joe wrote: > > > > I thought you might find more examples helpful. The man page says that > > policies come from /etc/polkit-1 and /var/lib/polkit-1, but on my > > system the /var/lib location is almost empty, and there's a lot > > in /usr/share/polkit-1, almost nothing in /etc/polkit-1. > > > > And, like I've said, thank you for your time. But those examples are all > policy files and local settings are done under > /etc/polkit-1/localauthority.conf.d/ for configuring which users, groups > or netgroups will be considered as admins for authentication, and under > /etc/polkit-1/localauthority/ directories with .pkla extension files > should be used for overriding policies with local settings. At least it > goes like that as far as I could deduct from man pages ( anyone thinking > that I did not understood that well, please correct me ). Now, files Your understanding is at least as good or better than mine (which isn't itself magnificent). > under /etc/polkit-1/localauthority.conf.d/ I understand, or at least > believe so. What I'm still searching for is better understanding of > those .pkla files. I've read those man pages some time ago, when I've > started with attempts to wrap my head around policikit, but was rather > busy after that and did not completely finish with it. If I understood > it right, about any .pkla file should look something like this: I think this is correct. > [ Description of what it does ] > Identity=unix-user:someuser;unix-user:someotheruser;unix-group:somegroup;unix-group:someothergroup;unix-netgroup:somegroup;unix-netgroup:someothergroup > Action=something.from.usr.share.polkit-1.actions > ResultAny=no/yes/auth_self/auth_admin/auth_self_keep/auth_admin_keep > ResultInactivee=same/options/as/above > ResultActive=same/options/as/above At least one of the last three lines is needed. But three is ok. > Now, what I believe is that for Identity and Action wildecards are > allowed and that there are no more options aside from ResultAny, The manual mentions globs. > ResultInactive and ResultActive that can follow Action part. And that > no, yes or other values will be returned to Defaults section in that > policy file defined under Action part and change whatever was defined > there. If someone with greater understanding of Polkit could tell me if > I got it right, or not, that would be great. In case that I did not get > that right, any point in right direction, or explanation would be great > too. The best way to understand is to ask for or give a specific example. Suppose Urs Thuermann has got over the shock his 10 years old son's actions gave him and he wanted never to experience such horror again. [No user rebooting, powering off etc] Identity=unix-user:* Action=org.freedesktop.login1.* ResultAny=no ResultActive=no ResultInactive=no should do it. That still leaves CTRL+ALT+DEL from a tty to be taken care of. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-12-09 21:10 +0100 |
| Message-ID | <uUTBE-6hG-3@gated-at.bofh.it> |
| In reply to | #189729 |
On Sat, Dec 09, 2017 at 06:20:01PM +0000, Jonathan Dowland wrote: > On Sat, 2017-12-09 at 10:00 +0000, Brian wrote: > > Consistencey can be achieved by not installing policykit. The OP > > appears to have chosen the wrong target.Consistencey can be achieved > by not installing policykit. > > As Michael pointed out in [1], that's not the case; prior to polkit, > there was no consistency. > There are multiple dimensions of consistency. PolicyKit may provide may provide consistency in terms of centralizing configuration so that various disparate components behave in some predictable fashion across those components. Without installing PolicyKit is the various components behave in their historically independent ways. That in itself is just a different form of consistency. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-12-09 21:10 +0100 |
| Message-ID | <uUTBE-6hG-11@gated-at.bofh.it> |
| In reply to | #189729 |
On Sat 09 Dec 2017 at 18:20:01 +0000, Jonathan Dowland wrote: > On Sat, 2017-12-09 at 10:00 +0000, Brian wrote: > > Consistencey can be achieved by not installing policykit. The OP > > appears to have chosen the wrong target.Consistencey can be achieved > by not installing policykit. > > As Michael pointed out in [1], that's not the case; prior to polkit, > there was no consistency. We are at cross-purposes. Don't install policykit and a pre-systemd and a systemd system behave in the same way wrt /sbin/reboot. Is this the sort of advice people think should have been in the Release Notes? -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2017-12-08 21:50 +0100 |
| Message-ID | <uUxKN-yn-3@gated-at.bofh.it> |
| In reply to | #189688 |
On Friday 08 December 2017 14:26:41 Jonathan Dowland wrote: > On Fri, Dec 08, 2017 at 07:09:06PM +0100, Menelaos Maglis wrote: > >>> > Basically, it was a completely inconsistent mess before systemd. > >>> > Now you at least have a central place where you can configure > >>> > your system behaviour. > >> > >> In the past, we had *no consistency*: inittab had one thing, > >> display managers another, ACPI scripts another...if you wanted a > >> specific policy, you had to change three or more separate systems. > >> > >> Along came [a new system] which provided a single place to define a > >> consistent policy. > > > >systemd provides a single place to define a consistent policy, > > provided your system uses systemd. > > That's a good point. > > >Debian GNU/Linux offers alternative init systems, which people choose > >and use. They have their, often different, "default" settings. > > It would perhaps be a good idea for the policy to be determined in an > init-agnostic way.o > > >In anycase, it should be a documented configuration option to allow > >for alternative use cases. > > No objection there, and I agree that the release notes should probably > have covered the policy changes. That ship has now sailed > unfortunately. So now, no effort will ever be made to fix the man pages. Hell of a way to run a train. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | linux.debian.user
csiph-web