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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Menelaos Maglis <mmaglis@metacom.gr> |
|---|---|
| Date | 2017-12-09 01:40 +0100 |
| Message-ID | <uUBln-2Wr-1@gated-at.bofh.it> |
| In reply to | #189699 |
Joe <joe@jretrading.com> writes: > I think there's a case for asking which way to set it during an expert > install or during the upgrade that reversed the default setting. I think it is policy not to touch locally changed configuration during upgrades. Usually packages ask what to do and/or provide information when parameters are deprecated or other important architectural changes are introduced in the new version. My expectation with Debian is that if I touch a (systemd) configuration file it wont be overridden during some upgrade. Of course, this will not occur if I have never touched the default configuration and some setting, /within the package/, changed to a new default. In this case, I expect some information in the upgrade manual and to be displayed during package upgrade. During upgrade from a sysvinit to a systemd release this was, correctly in my opinion, not handled by the systemd package; it was after all not changing any of /its/ default behavior. This should have been highlighted in the upgrade manual. Was the system behavior change found during upgrade tests? Was there a bug or discussion to highlight this system change in the upgrade manual? Were people more package-centric and failed to smooth the overall transition of the system? The heated discussions around systemd did not help either.
[toc] | [prev] | [next] | [standalone]
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2017-12-09 03:10 +0100 |
| Message-ID | <uUCKt-3Vx-3@gated-at.bofh.it> |
| In reply to | #189701 |
[Multipart message — attachments visible in raw view] — view raw
The OP has never been seen again since the original post. Just sayin’... On Sat, Dec 9, 2017 at 9:39 Menelaos Maglis <mmaglis@metacom.gr> wrote: > Joe <joe@jretrading.com> writes: > > > I think there's a case for asking which way to set it during an expert > > install or during the upgrade that reversed the default setting. > > I think it is policy not to touch locally changed configuration during > upgrades. Usually packages ask what to do and/or provide information > when parameters are deprecated or other important architectural changes > are introduced in the new version. > My expectation with Debian is that if I touch a (systemd) configuration > file it wont be overridden during some upgrade. > > Of course, this will not occur if I have never touched the default > configuration and some setting, /within the package/, changed to a new > default. In this case, I expect some information in the upgrade manual > and to be displayed during package upgrade. > > During upgrade from a sysvinit to a systemd release this was, correctly > in my opinion, not handled by the systemd package; it was after all not > changing any of /its/ default behavior. This should have been > highlighted in the upgrade manual. > > Was the system behavior change found during upgrade tests? > Was there a bug or discussion to highlight this system change in the > upgrade manual? > Were people more package-centric and failed to smooth the overall > transition of the system? > The heated discussions around systemd did not help either. > > >
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2017-12-09 10:50 +0100 |
| Message-ID | <uUJVE-8ni-11@gated-at.bofh.it> |
| In reply to | #189705 |
On Sat, 09 Dec 2017 01:46:59 +0000 Mark Fletcher <mark27q1@gmail.com> wrote: > The OP has never been seen again since the original post. Just > sayin’... > > Because he accidentally discovered a new feature, thought it was a bug, and was immediately corrected. End of story. We've been discussing the 'accidentally'. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Ric Moore <wayward4now@gmail.com> |
|---|---|
| Date | 2017-12-09 16:40 +0100 |
| Message-ID | <uUPom-3st-3@gated-at.bofh.it> |
| In reply to | #189697 |
On 12/08/2017 05:12 PM, Cindy-Sue Causey wrote: Something I did *not* understand when I saw it in > operation was why a password was needed at the terminal but not from > within the GUI's "Applications > Log Out" menu path. Thank you Cindy, now I don't have to point out the obvious! :) Ric -- My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. http://linuxcounter.net/user/44256.html
[toc] | [prev] | [next] | [standalone]
| From | Tom Furie <tom@furie.org.uk> |
|---|---|
| Date | 2017-12-09 17:10 +0100 |
| Message-ID | <uUPRo-3TB-19@gated-at.bofh.it> |
| In reply to | #189721 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Dec 09, 2017 at 10:17:45AM -0500, Ric Moore wrote: > On 12/08/2017 05:12 PM, Cindy-Sue Causey wrote: > > Something I did *not* understand when I saw it in operation was why > > a password was needed at the terminal but not from within the GUI's > > "Applications > Log Out" menu path. > > Thank you Cindy, now I don't have to point out the obvious! :) Ric Apart from the minor detail where in a properly network transparent environment X sessions do not always occur at the console. Cheers, Tom -- A man may sometimes be forgiven the kiss to which he is not entitled, but never the kiss he has not the initiative to claim.
[toc] | [prev] | [next] | [standalone]
| From | Ben Caradoc-Davies <ben@transient.nz> |
|---|---|
| Date | 2017-12-09 22:10 +0100 |
| Message-ID | <uUUxI-6RU-27@gated-at.bofh.it> |
| In reply to | #189724 |
On 10/12/17 04:45, Tom Furie wrote: > On Sat, Dec 09, 2017 at 10:17:45AM -0500, Ric Moore wrote: >> On 12/08/2017 05:12 PM, Cindy-Sue Causey wrote: >>> Something I did *not* understand when I saw it in operation was why >>> a password was needed at the terminal but not from within the GUI's >>> "Applications > Log Out" menu path. >> Thank you Cindy, now I don't have to point out the obvious! :) Ric > Apart from the minor detail where in a properly network transparent > environment X sessions do not always occur at the console. Polkit can tell the difference: - Local XFCE shutdown (debian/sid, systemd): no prompt - Remote XFCE shutdown via VNC tunnelled through SSH (Ubuntu 16.04 LTS, systemd): password prompt I think these are sensible defaults. Kind regards, -- Ben Caradoc-Davies <ben@transient.nz> Director Transient Software Limited <https://transient.nz/> New Zealand
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-12-09 18:20 +0100 |
| Message-ID | <uUQX8-4zw-3@gated-at.bofh.it> |
| In reply to | #189721 |
On Sat 09 Dec 2017 at 10:17:45 (-0500), Ric Moore wrote: > On 12/08/2017 05:12 PM, Cindy-Sue Causey wrote: > Something I did *not* understand when I saw it in > >operation was why a password was needed at the terminal but not from > >within the GUI's "Applications > Log Out" menu path. > > Thank you Cindy, now I don't have to point out the obvious! :) Ric I don't know what's obvious. I also don't know what is meant in the above by "terminal". Is it a linux VC (pre-X/DE), a VC summoned from X, a POX (plain old xterm) or some DE-moderated terminal that I've never used? It would also be nice to know what the command was that was typed. (I'm also assuming that systemd was likely installed, and we're talking stretch.) Sorry about all the alsos, but there are a lot of variables at play here. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2017-12-07 00:00 +0100 |
| Message-ID | <uTQPw-6eH-11@gated-at.bofh.it> |
| In reply to | #189609 |
On Wed, Dec 06, 2017 at 10:52:17PM +0100, Urs Thuermann wrote: >Yesterday, my 10 years old son logged into my laptop running Debian >jessie using his account, and curiously asked if he is allowed to try >the /sbin/reboot command. Knowing I have a Linux system as opposed to >some crappy Win machine, I replied "sure, go ahead and try". Seconds >later I was completely shocked when the machine actually rebooted... It's a feature. Users at the console can reboot, on the theory that if someone's sitting at the laptop they could also just push the power button... If they were logged in remotely, they would not be able to reboot. Mike Stone
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2017-12-07 09:40 +0100 |
| Message-ID | <uTZSO-3K6-11@gated-at.bofh.it> |
| In reply to | #189612 |
On Wed, 6 Dec 2017 17:35:18 -0500 Michael Stone <mstone@debian.org> wrote: > On Wed, Dec 06, 2017 at 10:52:17PM +0100, Urs Thuermann wrote: > >Yesterday, my 10 years old son logged into my laptop running Debian > >jessie using his account, and curiously asked if he is allowed to try > >the /sbin/reboot command. Knowing I have a Linux system as opposed > >to some crappy Win machine, I replied "sure, go ahead and try". > >Seconds later I was completely shocked when the machine actually > >rebooted... > > It's a feature. Users at the console can reboot, on the theory that > if someone's sitting at the laptop they could also just push the > power button... > I think the point here is that it never used to be, and I don't recall any publicity about the change. Of course, I'm a mere user, not a developer.... but I do read changelogs, and I've never seen it there. I've used a server since sarge, and never had the slightest trace of a GUI installed. I would therefore consider myself a console user, and I always had to use sudo to shutdown or reboot, or su on a new installation. There was never any difference, local or remote. Several years ago, I used to use LXDE on my workstation (between the introductions of Gnome3 and systemd on unstable, to date it) and one day it would not shut down from the desktop applet. I needed to open a terminal to shutdown, and *then* I needed to use sudo and a password. After doing it for a while with no fix, I switched to Xfce, which I've used since, for this precise reason. So it certainly used to work the other way around: DEs had workarounds so that root or sudo was not necessary to power off, but the console command did need root privileges. It may be different now, but it's a long time since I accidentally issued a shutdown command without root privileges, and I'm not going to do it at the moment. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Glenn English <ghe2001@gmail.com> |
|---|---|
| Date | 2017-12-07 00:10 +0100 |
| Message-ID | <uTQZb-6yW-3@gated-at.bofh.it> |
| In reply to | #189609 |
On Wed, Dec 6, 2017 at 9:52 PM, Urs Thuermann <urs@isnogud.escape.de> wrote: > Of course, my son doesn't have any special privileges, no entry in > /etc/sudoers, etc. But then I see > > $ ls -l /sbin/reboot > lrwxrwxrwx 1 root root 14 Apr 8 2017 /sbin/reboot -> /bin/systemctl > $ ls -l /bin/systemctl Same in Buster... -- Glenn English
[toc] | [prev] | [next] | [standalone]
| From | Brian <ad44@cityscape.co.uk> |
|---|---|
| Date | 2017-12-07 00:10 +0100 |
| Message-ID | <uTQZc-6yW-11@gated-at.bofh.it> |
| In reply to | #189609 |
On Wed 06 Dec 2017 at 22:52:17 +0100, Urs Thuermann wrote: > Yesterday, my 10 years old son logged into my laptop running Debian > jessie using his account, and curiously asked if he is allowed to try > the /sbin/reboot command. Knowing I have a Linux system as opposed to > some crappy Win machine, I replied "sure, go ahead and try". Seconds > later I was completely shocked when the machine actually rebooted... > > Of course, my son doesn't have any special privileges, no entry in > /etc/sudoers, etc. But then I see He is privileged because he has physical access to the machine. > > $ ls -l /sbin/reboot > lrwxrwxrwx 1 root root 14 Apr 8 2017 /sbin/reboot -> /bin/systemctl > $ ls -l /bin/systemctl > -rwxr-xr-x 1 root root 538904 Apr 8 2017 /bin/systemctl > $ dpkg -S /bin/systemctl > systemd: /bin/systemctl > > The /bin/systemctl binary is not suid root, so I assume[1] it > communicates to systemd which then reboots the machine without > checking what user the request comes from. > > I wonder how can such a severe bug make it into a Debian stable > distribution? And is this just an insane default setting on Debian's > side or is it yet another instance of brain-dead systemd behavior? A user with physical access to the machine can press the ON/OFF switch or pull the plug out or switch to a terminal and do CTL+ALT+DEL. Which one of these actions is a bug in Debian? > Searching the man pages I couldn't find a way to fix this. How can > that be stopped? A cast-iron solution for stopping a user with physical access to a machine from powering it off has been sought for ages. -- Brian.
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-12-07 03:50 +0100 |
| Message-ID | <uTUq6-7d-7@gated-at.bofh.it> |
| In reply to | #189615 |
On Wed, Dec 06, 2017 at 10:48:11PM +0000, Brian wrote: > On Wed 06 Dec 2017 at 22:52:17 +0100, Urs Thuermann wrote: > > > Yesterday, my 10 years old son logged into my laptop running Debian > > jessie using his account, and curiously asked if he is allowed to try > > the /sbin/reboot command. Knowing I have a Linux system as opposed to > > some crappy Win machine, I replied "sure, go ahead and try". Seconds > > later I was completely shocked when the machine actually rebooted... > > > > Of course, my son doesn't have any special privileges, no entry in > > /etc/sudoers, etc. But then I see > > He is privileged because he has physical access to the machine. > Not necessarily. It is falacious to assume that someone logging in via display manager or TTY has physical access. -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | Michael Lange <klappnase@freenet.de> |
|---|---|
| Date | 2017-12-07 00:20 +0100 |
| Message-ID | <uTR8S-6DS-1@gated-at.bofh.it> |
| In reply to | #189609 |
Hi, uh, I guess you ought to have used your time to check your machine and read some docs instead of figuring out how to best insult the debian developers ;) (scnr) On 06 Dec 2017 22:52:17 +0100 Urs Thuermann <urs@isnogud.escape.de> wrote: (...) > I wonder how can such a severe bug make it into a Debian stable > distribution? And is this just an insane default setting on Debian's > side or is it yet another instance of brain-dead systemd behavior? Maybe I am just a brain-dead loony, but personally I prefer to be able to shut down or reboot my system without having to type a password. If you do not like this behavior you might have to learn how to define polkit rules. Regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, "The City on the Edge of Forever", stardate unknown
[toc] | [prev] | [next] | [standalone]
| From | "James H. H. Lampert" <jamesl@touchtonecorp.com> |
|---|---|
| Date | 2017-12-07 00:50 +0100 |
| Message-ID | <uTRBT-6NU-1@gated-at.bofh.it> |
| In reply to | #189616 |
On 12/6/17, 2:53 PM, Michael Lange wrote: > uh, I guess you ought to have used your time to check your machine and > read some docs instead of figuring out how to best insult the debian > developers ;) > (scnr) Now, now, you walk up to the physical console on an AS/400, you're not going to be able to do a PWRDWNSYS from a sign-on screen, nor can do it if signed on as a user who doesn't have sufficient authority to do a PWRDWNSYS. And you might be physically locked out of the front panel. It's even possible that you might be physically interdicted from unplugging the box, or shutting it down from the circuit breaker panel. Not every OS assumes by default that anybody with physical access to the hardware also has the authority to shut it down. ;-p (And likewise, accounts, including QSECOFR [the closest OS/400 equivalent to root] can be restricted to certain physical terminals.) -- JHHL
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2017-12-07 01:20 +0100 |
| Message-ID | <uTS4V-7ex-9@gated-at.bofh.it> |
| In reply to | #189618 |
On Wed, Dec 06, 2017 at 03:25:10PM -0800, James H. H. Lampert wrote: >Now, now, you walk up to the physical console on an AS/400, you're not >going to be able to do a PWRDWNSYS from a sign-on screen, nor can do >it if signed on as a user who doesn't have sufficient authority to do >a PWRDWNSYS. And you might be physically locked out of the front >panel. It's even possible that you might be physically interdicted >from unplugging the box, or shutting it down from the circuit breaker >panel. > >Not every OS assumes by default that anybody with physical access to >the hardware also has the authority to shut it down. In the extremely unlikely event that you have your debian system configured with that level of physical access control, you can adjust the power/reboot permissions to suit your preferences. For most other users, the defaults are reasonable. The main realistic use case of a different default is kiosk systems, where changing the privileges given to locally logged in users is just one of the steps that should be taken. In general, defaults are chosen to be useful for the largest set of users. Side note: historically, people have always wanted to be able to reboot or shutdown the system they were sitting in front of. This led to a lot of really horrible solutions, like a bunch of setuid helper programs and one-off site specific hacks. Having this functionality standardized in one place is a net win for security, especially since there's also now a single standarized way to change the privileges. Mike Stone
[toc] | [prev] | [next] | [standalone]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2017-12-07 03:50 +0100 |
| Message-ID | <uTUq5-7d-1@gated-at.bofh.it> |
| In reply to | #189621 |
On Wed, Dec 06, 2017 at 06:56:12PM -0500, Michael Stone wrote: > > Side note: historically, people have always wanted to be able to reboot or > shutdown the system they were sitting in front of. This led to a lot of > really horrible solutions, like a bunch of setuid helper programs and > one-off site specific hacks. Having this functionality standardized in one > place is a net win for security, especially since there's also now a single > standarized way to change the privileges. > I don't necessarily disagree that having it centralized is a win. I do, however, think that it should have earned a mention in the release notes. Regards, -Roberto -- Roberto C. Sánchez
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2017-12-07 02:10 +0100 |
| Message-ID | <uTSRk-7LQ-3@gated-at.bofh.it> |
| In reply to | #189618 |
On Wed 06 Dec 2017 at 15:25:10 (-0800), James H. H. Lampert wrote: > On 12/6/17, 2:53 PM, Michael Lange wrote: > >uh, I guess you ought to have used your time to check your machine and > >read some docs instead of figuring out how to best insult the debian > >developers ;) > >(scnr) > > Now, now, you walk up to the physical console on an AS/400, you're > not going to be able to do a PWRDWNSYS from a sign-on screen, nor > can do it if signed on as a user who doesn't have sufficient > authority to do a PWRDWNSYS. And you might be physically locked out > of the front panel. It's even possible that you might be physically > interdicted from unplugging the box, or shutting it down from the > circuit breaker panel. I can't speak for your jurisdiction, but typically you can shut down a machine room without access to the room itself. I guess one reason for this is that the halon fire suppression would kill you on entry. With the Cambridge University computing service in the days of the 370/165, the cut-off switch was high on the wall in the "cafeteria" area (self-service card reader and line printer) which was open to users 24 hours a day. > Not every OS assumes by default that anybody with physical access to > the hardware also has the authority to shut it down. I didn't know we were talking about authority. One of the pastimes of kids in rough neighbourhoods is to pull the Engine Stop lever while a bus is picking up passengers. > (And likewise, accounts, including QSECOFR [the closest OS/400 > equivalent to root] can be restricted to certain physical > terminals.) Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Nicholas Geovanis <nickgeovanis@gmail.com> |
|---|---|
| Date | 2017-12-07 03:40 +0100 |
| Message-ID | <uTUgq-8vA-11@gated-at.bofh.it> |
| In reply to | #189622 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Dec 6, 2017 at 6:49 PM, David Wright <deblis@lionunicorn.co.uk> wrote: > On Wed 06 Dec 2017 at 15:25:10 (-0800), James H. H. Lampert wrote: > > > Now, now, you walk up to the physical console on an AS/400, you're > > not going to be able to do a PWRDWNSYS from a sign-on screen, nor > > can do it if signed on as a user who doesn't have sufficient > > authority to do a PWRDWNSYS. And you might be physically locked out > > of the front panel. It's even possible that you might be physically > > interdicted from unplugging the box, or shutting it down from the > > circuit breaker panel. > > With the Cambridge University computing service in the days of the > 370/165, the cut-off switch was high on the wall in the "cafeteria" > area (self-service card reader and line printer) which was open to > users 24 hours a day. As a former system admin for a university's 370/158 (yes, in the Jurassic), all I can say is, wow. That really wouldn't work in an American university (big surprise there...). None of that stuff was anywhere near a normal human being where I worked. > > Not every OS assumes by default that anybody with physical access to > > the hardware also has the authority to shut it down. > > I didn't know we were talking about authority. One of the pastimes > of kids in rough neighbourhoods is to pull the Engine Stop lever > while a bus is picking up passengers. And here they steal the conductors' keys on the subway and open the doors in mid-trip. So, we don't have conductors anymore, not for years. That's the American solution. But no one has picked-up the man's point: We deploy these machines as servers, thousands of them. This is desktop stuff that doesn't belong there, has no function there. If we're going to deploy these machines, why can't the manufacturers get a real, solid clue about physical security of the hardware? If the mainframes could do it 35 years ago why can't it be done today with smaller, discrete servers? Answer: It can be, but the manufacturers value their profit margin over your safety. And, well, it must be said: An AS/400 is no mainframe, it's a mini....Sorry dude ;-)
[toc] | [prev] | [next] | [standalone]
| From | Eric S Fraga <e.fraga@ucl.ac.uk> |
|---|---|
| Date | 2017-12-07 08:30 +0100 |
| Message-ID | <uTYN4-33Y-9@gated-at.bofh.it> |
| In reply to | #189624 |
[Multipart message — attachments visible in raw view] — view raw
On Wednesday, 6 Dec 2017 at 20:21, Nicholas Geovanis wrote: > As a former system admin for a university's 370/158 (yes, in the > Jurassic), all I can say is, wow. That really wouldn't work in an > American university (big surprise there...). None of that stuff was > anywhere near a normal human being where I worked. Yeah, I remember the big red button on the main console on our Amdahl 470. Very tempting... :-) but definitely not user accessible. -- Eric S Fraga via Emacs 27.0.50, org 9.1.4
[toc] | [prev] | [next] | [standalone]
| From | Michael Biebl <biebl@debian.org> |
|---|---|
| Date | 2017-12-07 00:50 +0100 |
| Message-ID | <uTRBU-6NU-3@gated-at.bofh.it> |
| In reply to | #189616 |
[Multipart message — attachments visible in raw view] — view raw
Am 06.12.2017 um 23:53 schrieb Michael Lange:
> Hi,
>
> uh, I guess you ought to have used your time to check your machine and
> read some docs instead of figuring out how to best insult the debian
> developers ;)
> (scnr)
>
> On 06 Dec 2017 22:52:17 +0100
> Urs Thuermann <urs@isnogud.escape.de> wrote:
>
> (...)
>> I wonder how can such a severe bug make it into a Debian stable
>> distribution? And is this just an insane default setting on Debian's
>> side or is it yet another instance of brain-dead systemd behavior?
>
> Maybe I am just a brain-dead loony, but personally I prefer to be able to
> shut down or reboot my system without having to type a password. If you
> do not like this behavior you might have to learn how to define
> polkit rules.
For the interested reader, see
/usr/share/polkit-1/actions/org.freedesktop.login1.policy
org.freedesktop.login1.power-off has the following defaults
<defaults>
<allow_any>auth_admin_keep</allow_any>
<allow_inactive>auth_admin_keep</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
As has already been mentioned, active, local users can shutdown/reboot
the system without requiring a password. This is intended behaviour (for
the reasons already mentioned) and can indeed be overridden by custom
polkit rules.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | linux.debian.user
csiph-web