Re: UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd)

[Erik Christiansen]

On 09.01.18 15:04, Christian Groessler wrote:
> I just edited the password file directly, "vipw" and "vipw -s", and renamed
> the pi user.

When doing that, there is merit in running pwck before any powerdown/reboot, 
as any illegality in a line stopped processing of all following when I
last tried mucking it up. (A good reason for the root entry to be first.)

And for vigr there's grpck.

That's all we had in the decades before the newfangled useradd stuff
came along.

Erik

Re: UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd)

[Christian Groessler]

On 01/09/18 16:01, Roberto C. Sánchez wrote:

Don't forget about occurrences of 'pi' in the group files (use 'vigr'
and 'vigr -s' to catch those).



Yep. Forgot to mention that.

regards,
chris

Re: UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd)

[Roberto C . Sánchez]

On Tue, Jan 09, 2018 at 03:04:03PM +0100, Christian Groessler wrote:
> On 01/09/18 04:49, Jason wrote:
> > > This I'd guess is important, if you have several users. I don't, except
> > > for amanda and nut, and thats only on this machine. All the rest have
> > > one user, me, known under various aliases because the idiot installer is
> > > now set to give the first user the machines name like pi or rock64. I
> > > spent a month trying to fix user 1000 to be me instead of pi on the pi.
> > On the Pi, this is what worked for me:
> > 
> > 1. Add a new user (and add him to group sudo). This user gets ID 1001.
> > $ sudo adduser tempuser
> > $ sudo adduser tempuser sudo
> > 
> > 2. Log out of user pi and log in as the newly created user.
> > 3. Delete user pi (pi must not have any processes running)
> > $ sudo deluser pi
> > 
> > 4. Add the desired username:
> > $ sudo adduser gene
> 
> 
> I just edited the password file directly, "vipw" and "vipw -s", and renamed
> the pi user.
> 
Don't forget about occurrences of 'pi' in the group files (use 'vigr'
and 'vigr -s' to catch those).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd)

[Christian Groessler]

On 01/09/18 04:49, Jason wrote:

This I'd guess is important, if you have several users. I don't, except
for amanda and nut, and thats only on this machine. All the rest have
one user, me, known under various aliases because the idiot installer is
now set to give the first user the machines name like pi or rock64. I
spent a month trying to fix user 1000 to be me instead of pi on the pi.

On the Pi, this is what worked for me:

1. Add a new user (and add him to group sudo). This user gets ID 1001.
$ sudo adduser tempuser
$ sudo adduser tempuser sudo

2. Log out of user pi and log in as the newly created user.

3. Delete user pi (pi must not have any processes running)

$ sudo deluser pi

4. Add the desired username:
$ sudo adduser gene



I just edited the password file directly, "vipw" and "vipw -s", and 
renamed the pi user.


regards,
chris

UID 1000 on Raspberry Pi (Was: Re: Embarrassing security bug in systemd)

[Jason]

On Sun, Dec 10, 2017 at 10:17:12PM -0500, Gene Heskett wrote:
> On Sunday 10 December 2017 19:02:49 David Wright wrote:
> 
> > On Sun 10 Dec 2017 at 16:43:02 (-0500), Gene Heskett wrote:

[...]

> >
> This I'd guess is important, if you have several users. I don't, except 
> for amanda and nut, and thats only on this machine. All the rest have 
> one user, me, known under various aliases because the idiot installer is 
> now set to give the first user the machines name like pi or rock64. I 
> spent a month trying to fix user 1000 to be me instead of pi on the pi.

On the Pi, this is what worked for me:

1. Add a new user (and add him to group sudo). This user gets ID 1001.
   $ sudo adduser tempuser
   $ sudo adduser tempuser sudo

2. Log out of user pi and log in as the newly created user.
   
3. Delete user pi (pi must not have any processes running)
   $ sudo deluser pi

4. Add the desired username:
   $ sudo adduser gene

Since no 1000 exists anymore you get UID 1000. If desired,
delete the temporary user and the deleted users' home directories.

It's possible the raspi-config utility might have a problem performing
certain actions with no pi user existing so you might want to be a bit
careful and make sure initial configuration is done before trying
this.

> It was like trying to excavate the pine island pirate treasure, so I 
> eventually gave it up and reinstalled the jessie image. Ditto on the 
> rock64, so the only thing common is the password. Fortunately an ssh -Y 
> usr@machine works just fine.
> 
> I would not call my wife computer illiterate, but the last machine she 
> had to use for report card preps, (she's a long retired music teacher) 
> was a Packard-Bell with an 80286 cpu and dos-3.1 on floppies. She could 
> do it by hand in 1/3rd of the time. I have set her down at prior 
> versions of this keyboard, but running a mouse is beyond her. She spent 
> 34 years teaching grade school music in the county school system.
> 
> > Hopefully tomás won't need to paraphrase this :)
> >
> > Cheers,
> > David.
> 
> 
> Cheers, Gene Heskett

-- 
Jason

Re: Embarrassing security bug in systemd

[John Hasler]

Gene writes:
> That is probably enough if the user is smart enough to know how to
> check, but if I pull a new iso of the install image today, will it be
> there for reading before I click install when booted to that live iso
> with no network access?

If your new ISO is the latest point release it will include all the
changes that went into that point release.  The previous point release,
however, is what it is.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Friday 15 December 2017 07:11:04 Christian Seiler wrote:

> Am 2017-12-08 21:31, schrieb Gene Heskett:
> > On Friday 08 December 2017 14:26:41 Jonathan Dowland wrote:
> >> 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.
>
> If you want to update the release notes, please file a bug against the
> 'release-notes' pseudo-package, ideally (but not necessarily) with the
> proposed wording change. (But please also check if someone else has
> already done so, so you don't cause a duplicate.)
>
> It _is_ possible to update the release notes after the fact; see e.g.
> https://bugs.debian.org/865632 for something that was added after the
> release of Stretch. (And there are other examples, see
> https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/
> for a full history of what has been changed in the release notes of
> Stretch so far, both before and after the release.)
>
That is probably enough if the user is smart enough to know how to check, 
but if I pull a new iso of the install image today, will it be there for 
reading before I click install when booted to that live iso with no 
network access?

That would seem to require a respin of the iso with a version number 
increment out in about the third place, and I don't see that being done.

I also don't see why a script hasn't been written to do exactly that, the 
only problem then, and which may be the showstopper, is in the bandwidth 
needed to update all the mirrors in a timely fashion. Perhaps some 
bandwidth could be saved by a bittorrent/rsync like approach where only 
the changes are transmitted/updated?

A text addendum, published whenever, makes more sense. But its existence 
needs to be made widely known. That does not appear to be the case now, 
leading to this candidate for the longest, most vociferous thread ever.

Thats my $0.02, which times 3 would buy a loaf of bread the year I was 
born. :)

> Regards,
> Christian


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 

Re: Embarrassing security bug in systemd

[Christian Seiler]

Am 2017-12-08 21:31, schrieb Gene Heskett:

On Friday 08 December 2017 14:26:41 Jonathan Dowland wrote:

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.


If you want to update the release notes, please file a bug against the
'release-notes' pseudo-package, ideally (but not necessarily) with the
proposed wording change. (But please also check if someone else has
already done so, so you don't cause a duplicate.)

It _is_ possible to update the release notes after the fact; see e.g.
https://bugs.debian.org/865632 for something that was added after the
release of Stretch. (And there are other examples, see
https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/
for a full history of what has been changed in the release notes of
Stretch so far, both before and after the release.)

Regards,
Christian

Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd)

[David Wright]

On Mon 11 Dec 2017 at 09:16:35 (-0500), rhkra...@gmail.com wrote:

> From the Wikipedia article on "Magnetic storage":
> 
> https://en.wikipedia.org/wiki/Magnetic_storage#Design
> 
> "For reliable storage of data, the recording material needs to resist self-
> demagnetisation, which occurs when the magnetic domains repel each other. 
> Magnetic domains written too densely together to a weakly magnetisable 
> material will degrade over time due to rotation of the magnetic moment one or 
> more domains to cancel out these forces. The domains rotate sideways to a 
> halfway position that weakens the readability of the domain and relieves the 
> magnetic stresses. Older hard disk drives used iron(III) oxide as the 
> magnetic 
> material, but current disks use a cobalt-based alloy.[1]"

The last sentence belongs at the end of the previous paragraph,
which explains two changes made in disk technology:
i  horizontal→vertical,
ii iron→cobalt.

> I have trouble understanding that 2nd sentence:

Yes, it doesn't parse, and it also doesn't clearly express which
domains (grains or regions) are meant at each mention of the term.

But before changing it, I'd want to check out the physics. 



 "Magnetic domains written too 
> densely together to a weakly magnetisable material will degrade over time due 
> to rotation of the magnetic moment one or more domains to cancel out these 
> forces." and would like to rewrite it to be more clear--I'll make an attempt 
> below--suggestions are welcome:
> 
> "Magnetic domains written too densely together to a weakly magnetisable 
> material will degrade over time--the magnetic forces which impact the disk 
> during rotation will cause one or more of the tiny magnetic domains to rotate 
> to (partialy) cancel out the intended magnetization (which stores the data)."
> 
> I'll probably also replace "too densely together" with either "too close 
> together" or "too densely".
> 
> Maybe I've combined too much of the third sentence into the second sentence 
> and it might stand rewriting as well.

Cheers,
David.

Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd)

[rhkramer]

Thanks!

On Monday, December 11, 2017 10:04:09 AM Joe wrote:
> On Mon, 11 Dec 2017 09:16:35 -0500
> 
> rhkra...@gmail.com wrote:
> > (Did hard disks ever use iron oxide?)
> 
> The rigid platters of IBM cartridges and packs (the things you see in
> computer rooms in films) did have brown oxide coatings. The surface of
> each 12 inch platter side stored a magnificent 2.5MB, or at least the
> version I used did. It was used in a system with an embedded DG Nova,
> and a competitive product of the time used the modern 8 inch floppy
> discs...

Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd)

[rhkramer]

On Monday, December 11, 2017 09:41:45 AM Darac Marjal wrote:
> On Mon, Dec 11, 2017 at 09:16:35AM -0500, rhkra...@gmail.com wrote:
> >   From the Wikipedia article on "Magnetic storage":

> >   https://en.wikipedia.org/wiki/Magnetic_storage#Design

> >   "For reliable storage of data, the recording material needs to resist
> >   self-demagnetisation, which occurs when the magnetic domains repel
> >   each other. Magnetic domains written too densely together to a weakly
> >   magnetisable material will degrade over time due to rotation of the
> >   [1]magnetic moment one or more domains to cancel out these forces. The
> >   domains rotate sideways to a halfway position that weakens the
> >   readability of the domain and relieves the magnetic stresses. Older
> >   hard disk drives used [2]iron(III) oxide as the magnetic material, but
> >   current disks use a [3]cobalt-based alloy.[4][1]"
 
> >   I have trouble understanding that 2nd sentence: "Magnetic domains
> >   written too densely together to a weakly magnetisable material will
> >   degrade over time due to rotation of the [5]magnetic moment one or
> >   more domains to cancel out these forces." and would like to rewrite it
> >   to be more clear--I'll make an attempt below--suggestions are welcome:

> >   "Magnetic domains written too densely together to a weakly magnetisable
> >   material will degrade over time--the magnetic forces which impact the
> >   disk during rotation will cause one or more of the tiny magnetic
> >   domains to rotate to (partialy) cancel out the intended magnetization
> >   (which stores the data)."
> 
> Be careful. As I understand it, the force which causes the
> demagnetisation has little, if anything, to do with rotation of the
> platter. Rather, the problem lies in the fact that, let's say you have
> 1-0-1 stored on the disk, those two 1s provide a force which "pulls" on
> the 0 until it looks more like a 1 than a 0.

Ok--thanks for the reply.  I guess I'll wait until I acquire more information 
/ understanding (perhaps by osmosis--i.e., probably passively rather than by 
active (re-)search).

I guess part of my (the?) problem is the word rotation in the first iteration 
of the sentence--I assumed that was rotation of the disk (in things like (1) 
the magnetic fields associated with the read (and write) heads, and (2) maybe 
the earth's magnetic field.  

Maybe the interpretation of the word rotation is more like you imply--rotation 
of the magnetic field of the (for example) 0 in response to the two adjacent 
1s.

I guess the more I re-read that sentence, the more I tend to think that your 
interpretation is the correct one.

Any hints appreciated.

> >   I'll probably also replace "too densely together" with either "too
> >   close together" or "too densely".
> >   
> >
> >   
> >   Maybe I've combined too much of the third sentence into the second
> >   sentence and it might stand rewriting as well.
> >   
> >
> >
> >References
> >
> >   Visible links
> >   1. https://en.wikipedia.org/wiki/Magnetic_moment
> >   2. https://en.wikipedia.org/wiki/Iron%28III%29_oxide
> >   3. https://en.wikipedia.org/wiki/Cobalt
> >   4. https://en.wikipedia.org/wiki/Magnetic_storage#cite_note-AutoMK-13-1
> >   5. https://en.wikipedia.org/wiki/Magnetic_moment

Re: Embarrassing security bug in systemd

[David Wright]

On Mon 11 Dec 2017 at 11:32:54 (+), Eduardo M KALINOWSKI wrote:
> On dom, 10 dez 2017, tomas wrote:
> >To put it differently, Debian tends to package docs separately, because
> >you might want to set up a storage-constrained system where you don't
> >want that extra stuff. To me, that makes sense.
> 
> It also helps the archives, since there can be one
> architecture-independent .deb with the docs, and then smaller
> architecture-dependent .deb's with the binaries for each
> architecture, instead of duplicating the docs in those
> architecture-dependent packages.

Yes, bundling the docs with the binaries would be even worse.
But I didn't think Gene was ever arguing for that, only for
adding a docs dependency to the binary packages, which would
bloat each and every installation.

Cheers,
David.

Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd)

[Joe]

On Mon, 11 Dec 2017 09:16:35 -0500
rhkra...@gmail.com wrote:


> 
> (Did hard disks ever use iron oxide?)
> 

The rigid platters of IBM cartridges and packs (the things you see in
computer rooms in films) did have brown oxide coatings. The surface of
each 12 inch platter side stored a magnificent 2.5MB, or at least the
version I used did. It was used in a system with an embedded DG Nova,
and a competitive product of the time used the modern 8 inch floppy
discs...

-- 
Joe

Re: Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd)

[Darac Marjal]

On Mon, Dec 11, 2017 at 09:16:35AM -0500, rhkra...@gmail.com wrote:

  On Monday, December 11, 2017 01:12:41 AM Gene Heskett wrote:

  > There are instructions for making the pi's boot from rust, but its a one

  > way as its said to be an otp rom in charge of that, however when I try

  > to set that bit, its write protected even for root. In all 3 of the pi's

  > I bought. And there is even less info around on how the rock64 boots.

   

  I know "rust" is used as sort of a slang term, but do hard disks have iron 
oxide anywhere on them? When I take a hard disk
  apart (I save the magnets and melt the media), the disks are nice and shiny.

   

  (Did hard disks ever use iron oxide?)

   

  I guess I can google, and will try that later today. Oh, well:

   

  From the Wikipedia article on "Magnetic storage":

   

  https://en.wikipedia.org/wiki/Magnetic_storage#Design

   

  "For reliable storage of data, the recording material needs to resist 
self-demagnetisation, which occurs when the magnetic
  domains repel each other. Magnetic domains written too densely together to a 
weakly magnetisable material will degrade over
  time due to rotation of the [1]magnetic moment one or more domains to cancel 
out these forces. The domains rotate sideways
  to a halfway position that weakens the readability of the domain and relieves 
the magnetic stresses. Older hard disk drives
  used [2]iron(III) oxide as the magnetic material, but current disks use a 
[3]cobalt-based alloy.[4][1]"

   

  I have trouble understanding that 2nd sentence: "Magnetic domains written too 
densely together to a weakly magnetisable
  material will degrade over time due to rotation of the [5]magnetic moment one or 
more domains to cancel out these forces."
  and would like to rewrite it to be more clear--I'll make an attempt 
below--suggestions are welcome:

   

  "Magnetic domains written too densely together to a weakly magnetisable 
material will degrade over time--the magnetic forces
  which impact the disk during rotation will cause one or more of the tiny 
magnetic domains to rotate to (partialy) cancel out
  the intended magnetization (which stores the data)."


Be careful. As I understand it, the force which causes the 
demagnetisation has little, if anything, to do with rotation of the 
platter. Rather, the problem lies in the fact that, let's say you have 
1-0-1 stored on the disk, those two 1s provide a force which "pulls" on 
the 0 until it looks more like a 1 than a 0.




   

  I'll probably also replace "too densely together" with either "too close together" or 
"too densely".

   

  Maybe I've combined too much of the third sentence into the second sentence 
and it might stand rewriting as well.

   

References

  Visible links
  1. https://en.wikipedia.org/wiki/Magnetic_moment
  2. https://en.wikipedia.org/wiki/Iron%28III%29_oxide
  3. https://en.wikipedia.org/wiki/Cobalt
  4. https://en.wikipedia.org/wiki/Magnetic_storage#cite_note-AutoMK-13-1
  5. https://en.wikipedia.org/wiki/Magnetic_moment


--
For more information, please reread.


signature.asc
Description: PGP signature

Rust? (and a wordsmithing question) (was: Re: Embarrassing security bug in systemd)

[rhkramer]

On Monday, December 11, 2017 01:12:41 AM Gene Heskett wrote:
> There are instructions for making the pi's boot from rust, but its a one
> way as its said to be an otp rom in charge of that, however when I try
> to set that bit, its write protected even for root. In all 3 of the pi's
> I bought.  And there is even less info around on how the rock64 boots.

I know "rust" is used as sort of a slang term, but do hard disks have iron 
oxide anywhere on them?  When I take a hard disk apart (I save the magnets and 
melt the media), the disks are nice and shiny.

(Did hard disks ever use iron oxide?)

I guess I can google, and will try that later today.  Oh, well:

From the Wikipedia article on "Magnetic storage":

https://en.wikipedia.org/wiki/Magnetic_storage#Design

"For reliable storage of data, the recording material needs to resist self-
demagnetisation, which occurs when the magnetic domains repel each other. 
Magnetic domains written too densely together to a weakly magnetisable 
material will degrade over time due to rotation of the magnetic moment one or 
more domains to cancel out these forces. The domains rotate sideways to a 
halfway position that weakens the readability of the domain and relieves the 
magnetic stresses. Older hard disk drives used iron(III) oxide as the magnetic 
material, but current disks use a cobalt-based alloy.[1]"

I have trouble understanding that 2nd sentence: "Magnetic domains written too 
densely together to a weakly magnetisable material will degrade over time due 
to rotation of the magnetic moment one or more domains to cancel out these 
forces." and would like to rewrite it to be more clear--I'll make an attempt 
below--suggestions are welcome:

"Magnetic domains written too densely together to a weakly magnetisable 
material will degrade over time--the magnetic forces which impact the disk 
during rotation will cause one or more of the tiny magnetic domains to rotate 
to (partialy) cancel out the intended magnetization (which stores the data)."

I'll probably also replace "too densely together" with either "too close 
together" or "too densely".

Maybe I've combined too much of the third sentence into the second sentence 
and it might stand rewriting as well.

Re: Embarrassing security bug in systemd

[Brian]

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.

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Dec 11, 2017 at 07:19:20AM -0500, Gene Heskett wrote:
> On Monday 11 December 2017 06:02:46 Brian wrote:
> 
> > On Sun 10 Dec 2017 at 18:25:26 -0500, Gene Heskett wrote:
> > > apt can't do a show --uninstalled on the stretch machine, and the
> > > man page isn't offering much either, so to see whats available, I
> > > have to go to its own keyboard and run synaptic-pkexec.
> >
> > The apt man page isn't unhelpful. For available packages which are not
> > installed:
> >
> > apt list --all-versions | grep -v installed | less
> 
> which man page? Not even a hint of useing grep as above in the apt man 
> page,

This is more standard Unix fare. You look at apt's output and see how
you filter it with grep. Apt's man page can't cover grep (and all of
the other filters available to you).

>   which is where one would normally look for the applicable syntax. 
> You do find it in the grep man page. So I would call the apt man page 
> unhelpful.

See above. The apt man page would become unwieldy that way. Would you
include apt in the grep man page too?

Composition of commands is at the heart of Unix[1]. That's why the
commands are usually built to input/output text, to enable you to
stick them together. A big Lego set, if you want.

Cheers

[1] https://en.wikipedia.org/wiki/Unix_philosophy
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlouhLAACgkQBcgs9XrR2kb+PACfUseTu14Mobdn6607a4ejZHjj
P1UAn2/qYQfpaAOa2k5/I7gTLBm1JBMY
=yrWM
-END PGP SIGNATURE-

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Dec 11, 2017 at 11:32:54AM +, Eduardo M KALINOWSKI wrote:
[...]

> It also helps the archives, since there can be one
> architecture-independent .deb with the docs, and then smaller
> architecture-dependent .deb's with the binaries for each
> architecture, instead of duplicating the docs in those
> architecture-dependent packages.

Very true, thanks.

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAloueMMACgkQBcgs9XrR2kZ5rACcDf7gYynIUstlikqilzEypgcF
W0AAn2Hs0sOrBr7RPhTdFeINQJXouVng
=0/Tj
-END PGP SIGNATURE-

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Monday 11 December 2017 06:02:46 Brian wrote:

> On Sun 10 Dec 2017 at 18:25:26 -0500, Gene Heskett wrote:
> > apt can't do a show --uninstalled on the stretch machine, and the
> > man page isn't offering much either, so to see whats available, I
> > have to go to its own keyboard and run synaptic-pkexec.
>
> The apt man page isn't unhelpful. For available packages which are not
> installed:
>
> apt list --all-versions | grep -v installed | less

which man page? Not even a hint of useing grep as above in the apt man 
page, which is where one would normally look for the applicable syntax. 
You do find it in the grep man page. So I would call the apt man page 
unhelpful.

This obviously would work just fine, thank you Brian.

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 

Re: Embarrassing security bug in systemd

[Eduardo M KALINOWSKI]

On dom, 10 dez 2017, tomas wrote:

To put it differently, Debian tends to package docs separately, because
you might want to set up a storage-constrained system where you don't
want that extra stuff. To me, that makes sense.


It also helps the archives, since there can be one  
architecture-independent .deb with the docs, and then smaller  
architecture-dependent .deb's with the binaries for each architecture,  
instead of duplicating the docs in those architecture-dependent  
packages.


--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: Embarrassing security bug in systemd

[Brian]

On Sun 10 Dec 2017 at 18:25:26 -0500, Gene Heskett wrote:

> apt can't do a show --uninstalled on the stretch machine, and the man 
> page isn't offering much either, so to see whats available, I have to go 
> to its own keyboard and run synaptic-pkexec.

The apt man page isn't unhelpful. For available packages which are not
installed:

apt list --all-versions | grep -v installed | less

-- 
Brian.

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Sunday 10 December 2017 23:50:13 David Wright wrote:

> On Sun 10 Dec 2017 at 22:17:12 (-0500), Gene Heskett wrote:
> > On Sunday 10 December 2017 19:02:49 David Wright wrote:
> > > On Sun 10 Dec 2017 at 16:43:02 (-0500), Gene Heskett wrote:
> > > > On Sunday 10 December 2017 14:12:09 David Wright wrote:
> > > > > On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> > > > > > For something that can be such a pita, not installing the
> > > > > > docs doesn't seem like my error, they should have been part
> > > > > > of the install. IMO.
> > > > >
> > > > > That's ridiculous. I don't want all the docs on all the
> > > > > installations. I only install docs on the machines that either
> > > > > I'm going to read it on or one with a big disk.
> > > > >
> > > > > Cheers,
> > > > > David.
> > > >
> > > > While I do have spinning rust drives of a terrabyte on both of
> > > > those credit card sized machines, functioning as swaps and work
> > > > areas, they are still booting and running from a 32GB sd chip
> > > > disk.
> > >
> > > …whereas the two laptops I mainly type into have respectively 60
> > > and 80 GB disks of rust. Both have two root filesystems with
> > > different versions of Debian. The smaller drive's PC needs a swap
> > > partition to function, the other needs one for hibernation. Not a
> > > lot of space left for /home. Installing shedloads of docs for each
> > > person's PITA would contravene Debian's sensible policies.
> >
> > This I'd guess is important, if you have several users. I don't,
> > except for amanda and nut, and thats only on this machine. All the
> > rest have one user, me, known under various aliases
>
> That's not what I meant.
>
> You find polkit a PITA, so you want Debian to install the docs
> automatically when you install the package.
>
> Someone else finds ntp a PITA, so they lobby Debian for ntp's docs.
>
> "What about rsyslog?" says somebody else. "That should have the
> same treatment; it's a PITA."
>
> Debian's answer: if you want the docs for foo, then install foo-doc,
> but don't force them onto others by making them a dependency of foo.
>
> >   because the idiot
> > installer is now set to give the first user the machines name like
> > pi or rock64. I spent a month trying to fix user 1000 to be me
> > instead of pi on the pi.
>
> Have you tried setting the hostname to "gene" whenever you install
> onto a new machine, and then changing *its* name to pi or rock64
> afterwards. That might be easier.
>
> Cheers,
> David.

Thats a great idea David, except the installs on an armhf or arm64 are 
the complete image, and the install is a dd session with the sdcard in a 
card reader. So its rather effectively carved in pretty hard granite. :(

I don't even know if there is an install iso for an arm64 from debian. 
Neither of these seem to come with enough of a bios to actually boot and 
install, not from a usb key, and certainly not from an optical drive.  
No trace of a grub anyplace once its been done either.

There are instructions for making the pi's boot from rust, but its a one 
way as its said to be an otp rom in charge of that, however when I try 
to set that bit, its write protected even for root. In all 3 of the pi's 
I bought.  And there is even less info around on how the rock64 boots.

Frustrating...

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 

Re: Embarrassing security bug in systemd

[David Wright]

On Sun 10 Dec 2017 at 22:17:12 (-0500), Gene Heskett wrote:
> On Sunday 10 December 2017 19:02:49 David Wright wrote:
> 
> > On Sun 10 Dec 2017 at 16:43:02 (-0500), Gene Heskett wrote:
> > > On Sunday 10 December 2017 14:12:09 David Wright wrote:
> > > > On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> > > > > For something that can be such a pita, not installing the docs
> > > > > doesn't seem like my error, they should have been part of the
> > > > > install. IMO.
> > > >
> > > > That's ridiculous. I don't want all the docs on all the
> > > > installations. I only install docs on the machines that either I'm
> > > > going to read it on or one with a big disk.
> > > >
> > > > Cheers,
> > > > David.
> > >
> > > While I do have spinning rust drives of a terrabyte on both of those
> > > credit card sized machines, functioning as swaps and work areas,
> > > they are still booting and running from a 32GB sd chip disk.
> >
> > …whereas the two laptops I mainly type into have respectively 60 and
> > 80 GB disks of rust. Both have two root filesystems with different
> > versions of Debian. The smaller drive's PC needs a swap partition to
> > function, the other needs one for hibernation. Not a lot of space
> > left for /home. Installing shedloads of docs for each person's PITA
> > would contravene Debian's sensible policies.
> >
> This I'd guess is important, if you have several users. I don't, except 
> for amanda and nut, and thats only on this machine. All the rest have 
> one user, me, known under various aliases

That's not what I meant.

You find polkit a PITA, so you want Debian to install the docs
automatically when you install the package.

Someone else finds ntp a PITA, so they lobby Debian for ntp's docs.

"What about rsyslog?" says somebody else. "That should have the
same treatment; it's a PITA."

Debian's answer: if you want the docs for foo, then install foo-doc,
but don't force them onto others by making them a dependency of foo.

>   because the idiot installer is 
> now set to give the first user the machines name like pi or rock64. I 
> spent a month trying to fix user 1000 to be me instead of pi on the pi.

Have you tried setting the hostname to "gene" whenever you install
onto a new machine, and then changing *its* name to pi or rock64
afterwards. That might be easier.

Cheers,
David.

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Sunday 10 December 2017 19:02:49 David Wright wrote:

> On Sun 10 Dec 2017 at 16:43:02 (-0500), Gene Heskett wrote:
> > On Sunday 10 December 2017 14:12:09 David Wright wrote:
> > > On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> > > > For something that can be such a pita, not installing the docs
> > > > doesn't seem like my error, they should have been part of the
> > > > install. IMO.
> > >
> > > That's ridiculous. I don't want all the docs on all the
> > > installations. I only install docs on the machines that either I'm
> > > going to read it on or one with a big disk.
> > >
> > > Cheers,
> > > David.
> >
> > While I do have spinning rust drives of a terrabyte on both of those
> > credit card sized machines, functioning as swaps and work areas,
> > they are still booting and running from a 32GB sd chip disk.
>
> …whereas the two laptops I mainly type into have respectively 60 and
> 80 GB disks of rust. Both have two root filesystems with different
> versions of Debian. The smaller drive's PC needs a swap partition to
> function, the other needs one for hibernation. Not a lot of space
> left for /home. Installing shedloads of docs for each person's PITA
> would contravene Debian's sensible policies.
>
This I'd guess is important, if you have several users. I don't, except 
for amanda and nut, and thats only on this machine. All the rest have 
one user, me, known under various aliases because the idiot installer is 
now set to give the first user the machines name like pi or rock64. I 
spent a month trying to fix user 1000 to be me instead of pi on the pi.

It was like trying to excavate the pine island pirate treasure, so I 
eventually gave it up and reinstalled the jessie image. Ditto on the 
rock64, so the only thing common is the password. Fortunately an ssh -Y 
usr@machine works just fine.

I would not call my wife computer illiterate, but the last machine she 
had to use for report card preps, (she's a long retired music teacher) 
was a Packard-Bell with an 80286 cpu and dos-3.1 on floppies. She could 
do it by hand in 1/3rd of the time. I have set her down at prior 
versions of this keyboard, but running a mouse is beyond her. She spent 
34 years teaching grade school music in the county school system.

> Hopefully tomás won't need to paraphrase this :)
>
> Cheers,
> David.


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 

Re: Embarrassing security bug in systemd

[David Wright]

On Sun 10 Dec 2017 at 16:43:02 (-0500), Gene Heskett wrote:
> On Sunday 10 December 2017 14:12:09 David Wright wrote:
> 
> > On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> > > For something that can be such a pita, not installing the docs
> > > doesn't seem like my error, they should have been part of the
> > > install. IMO.
> >
> > That's ridiculous. I don't want all the docs on all the installations.
> > I only install docs on the machines that either I'm going to read it
> > on or one with a big disk.
> >
> > Cheers,
> > David.
> 
> While I do have spinning rust drives of a terrabyte on both of those 
> credit card sized machines, functioning as swaps and work areas, they 
> are still booting and running from a 32GB sd chip disk.

…whereas the two laptops I mainly type into have respectively 60 and
80 GB disks of rust. Both have two root filesystems with different
versions of Debian. The smaller drive's PC needs a swap partition to
function, the other needs one for hibernation. Not a lot of space
left for /home. Installing shedloads of docs for each person's PITA
would contravene Debian's sensible policies.

Hopefully tomás won't need to paraphrase this :)

Cheers,
David.

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Sunday 10 December 2017 17:45:36 Brian wrote:

> On Sun 10 Dec 2017 at 16:47:05 -0500, Gene Heskett wrote:
> > On Sunday 10 December 2017 15:05:04 Brian wrote:
> > > On Sun 10 Dec 2017 at 13:12:09 -0600, David Wright wrote:
> > > > On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> > > > > For something that can be such a pita, not installing the docs
> > > > > doesn't seem like my error, they should have been part of the
> > > > > install. IMO.
> > > >
> > > > That's ridiculous. I don't want all the docs on all the
> > > > installations. I only install docs on the machines that either
> > > > I'm going to read it on or one with a big disk.
> > >
> > > I believe you are expressing what is standard practice. If you
> > > want any documentation which is packaged separately from the
> > > package itself, you have to request it. "apt-cache show..." or
> > > "apt show..." are very useful.
> >
> > I expect so, Brian, but one must pipe that output to less as it
> > could be a 100 meg long list. Not impossible, but inconvenient.
>
>   brian@desktop:~$ time apt search "\-doc" > docfile
>   real0m1.793s
>   user0m1.480s
>   sys 0m0.168s
>
> 100 meg is an overestimate.
>
Is it? I was referring to the repo lists that would be parsed by show. 
And displayed by synaptic as not installed but available packages. That 
list can be 20,000 lines of text.
apt can't do a show --uninstalled on the stretch machine, and the man 
page isn't offering much either, so to see whats available, I have to go 
to its own keyboard and run synaptic-pkexec.

An apt list on that stretch is 50288 lines. Best inspected with less. :)

>   brian@desktop:~$ ls -l docfile
>   -rw-r--r-- 1 brian brian 355847 Dec 10 22:35 docfile
>
>   brian@desktop:~$ apt search "\-doc" | grep policy
>   policykit-1-doc/stable 0.105-18 all
> client for the open policy framework for the cloud - doc
>   python-oslo.policy-doc/stable 1.14.0-2 all
> RBAC policy enforcement library for OpenStack - doc
>   selinux-policy-doc/stable 2:2.20161023.1-9 all
> Documentation for the SELinux reference policy
>
> Suggestions for something less inconvenient are welcome.

I have to agree, Brian.

Thanks.

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 

Re: Embarrassing security bug in systemd

[Brian]

On Sun 10 Dec 2017 at 16:47:05 -0500, Gene Heskett wrote:

> On Sunday 10 December 2017 15:05:04 Brian wrote:
> 
> > On Sun 10 Dec 2017 at 13:12:09 -0600, David Wright wrote:
> > > On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> > > > For something that can be such a pita, not installing the docs
> > > > doesn't seem like my error, they should have been part of the
> > > > install. IMO.
> > >
> > > That's ridiculous. I don't want all the docs on all the
> > > installations. I only install docs on the machines that either I'm
> > > going to read it on or one with a big disk.
> >
> > I believe you are expressing what is standard practice. If you want
> > any documentation which is packaged separately from the package
> > itself, you have to request it. "apt-cache show..." or "apt show..."
> > are very useful.
> 
> I expect so, Brian, but one must pipe that output to less as it could be 
> a 100 meg long list. Not impossible, but inconvenient.

  brian@desktop:~$ time apt search "\-doc" > docfile
  real0m1.793s
  user0m1.480s
  sys 0m0.168s

100 meg is an overestimate.

  brian@desktop:~$ ls -l docfile
  -rw-r--r-- 1 brian brian 355847 Dec 10 22:35 docfile

  brian@desktop:~$ apt search "\-doc" | grep policy
  policykit-1-doc/stable 0.105-18 all
client for the open policy framework for the cloud - doc
  python-oslo.policy-doc/stable 1.14.0-2 all
RBAC policy enforcement library for OpenStack - doc
  selinux-policy-doc/stable 2:2.20161023.1-9 all
Documentation for the SELinux reference policy

Suggestions for something less inconvenient are welcome.

-- 
Brian.

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Sunday 10 December 2017 15:05:04 Brian wrote:

> On Sun 10 Dec 2017 at 13:12:09 -0600, David Wright wrote:
> > On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> > > For something that can be such a pita, not installing the docs
> > > doesn't seem like my error, they should have been part of the
> > > install. IMO.
> >
> > That's ridiculous. I don't want all the docs on all the
> > installations. I only install docs on the machines that either I'm
> > going to read it on or one with a big disk.
>
> I believe you are expressing what is standard practice. If you want
> any documentation which is packaged separately from the package
> itself, you have to request it. "apt-cache show..." or "apt show..."
> are very useful.

I expect so, Brian, but one must pipe that output to less as it could be 
a 100 meg long list. Not impossible, but inconvenient.

Thanks Brian.

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 

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Sunday 10 December 2017 14:12:09 David Wright wrote:

> On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> > For something that can be such a pita, not installing the docs
> > doesn't seem like my error, they should have been part of the
> > install. IMO.
>
> That's ridiculous. I don't want all the docs on all the installations.
> I only install docs on the machines that either I'm going to read it
> on or one with a big disk.
>
> Cheers,
> David.

While I do have spinning rust drives of a terrabyte on both of those 
credit card sized machines, functioning as swaps and work areas, they 
are still booting and running from a 32GB sd chip disk. Which means any 
docs installed still are installed on the root filesystem, and on that 
32GB sd drive. But those are also the problem children. df says one is 
25% used, the other is 31% used. It was suggested by apt that I install 
devhelp, which I did on the rock64, but failed on the pi because I have 
pinned the realtime kernel on it, needed to run linuxcnc.

I hope to eventually install an rtai patched kernel on the rock64 so I 
can make a few passes at building the pi's spi driver, which is part of 
linuxcnc and which 5 to 500 times faster than the kernel's own spi 
driver. I can write 4 byte packets on the severely i/o crippled pi whose 
spi doesn't have to go thru the builtin usb hub to get to the spi, over 
a 1" cable, at 41 megabaud, and read the responses from the i/o card at 
25 megabaud. 

Putting a rock64 on that elderly Sheldon lathe, to replace the pi with 
its penchant for dropping keyboard and mouse events on the floor, will 
be one heck of an improvement.

Try that on the linux spi.ko driver and record the speeds obtained on a 
digital scope. Very enlightening. :)

If I fill it up and crash, well, theres even 128GB sd memories available, 
at a price of course. :)

Thank you David.

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 

Re: Embarrassing security bug in systemd

[Brian]

On Sat 09 Dec 2017 at 18:36:46 -0500, The Wanderer wrote:

> On 2017-12-09 at 09:10, Brian wrote:
> 
> > The Terms and Conditions of installing a Debian package include (as 
> > I'm sure you are aware) accepting the Depends: and Recomends: lines. 
> > What is in these lines can be accepted or rejected and, in the case 
> > of Recommends:, adjusted to suit your needs. Installing the package 
> > necessarily involves making an explicit request for other packages.
> 
> No, it doesn't. That's the exact distinction between "explicit" and
> "implicit".

Indeed. I used Joes's original word because I wasn't in a
nit-picking mood.

-- 
Brian.

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, Dec 10, 2017 at 01:12:09PM -0600, David Wright wrote:
> On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> 
> > For something that can be such a pita, not installing the docs doesn't 
> > seem like my error, they should have been part of the install. IMO.
> 
> That's ridiculous. I don't want all the docs on all the installations.
> I only install docs on the machines that either I'm going to read it on
> or one with a big disk.

To put it differently, Debian tends to package docs separately, because
you might want to set up a storage-constrained system where you don't
want that extra stuff. To me, that makes sense.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlotmM4ACgkQBcgs9XrR2kZv9QCdGMIyH5t9X/kwwGujBqGxjK2r
UtAAmwRWPNVk+Jz4saSy2Ee257OwRc80
=XdPv
-END PGP SIGNATURE-

Re: Embarrassing security bug in systemd

[Brian]

On Sun 10 Dec 2017 at 13:12:09 -0600, David Wright wrote:

> On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:
> 
> > For something that can be such a pita, not installing the docs doesn't 
> > seem like my error, they should have been part of the install. IMO.
> 
> That's ridiculous. I don't want all the docs on all the installations.
> I only install docs on the machines that either I'm going to read it on
> or one with a big disk.

I believe you are expressing what is standard practice. If you want
any documentation which is packaged separately from the package itself,
you have to request it. "apt-cache show..." or "apt show..." are very
useful.

-- 
Brian.

Re: Embarrassing security bug in systemd

[David Wright]

On Sun 10 Dec 2017 at 00:38:12 (-0800), Jimmy Johnson wrote:
> On 12/09/2017 08:23 AM, David Wright wrote:
> >On Fri 08 Dec 2017 at 18:30:08 (-0800), Jimmy Johnson wrote:
> >>On 12/07/2017 02:31 AM, Jonathan Dowland wrote:
> >>>On Thu, Dec 07, 2017 at 10:02:56AM +, Tixy wrote:
> I'm running Jessie (with systemd running but booting with sysvinit) and
> trying to execute halt/poweroff/reboot/shutdown from a terminal without
> root privileges gives an error saying I must be superuser. Which has
> always been my experience in 10 years of using Debian.
> >>>
> >>>Be careful to double check what you are testing: in your situation it's
> >>>not clear whether /sbin/reboot is a symlink to systemctl (part of
> >>>systemd, so I would expect this not to work if you were not running
> >>>systemd as the init system) or a separate binary.
> >>
> >>
> >>Jonathan, I started thinking about lost work where someone restarted
> >>the computer while I was away from it and thought what if you can
> >>lock-screen and lock access to console at the same time.  Is that
> >>something that could be done? Helpful?
> >>
> >>I know someone can pull the cord or press the power button, I got past that.
> >
> >I use vlock -a in a VC to lock all the consoles. I've been using
> >it for years so I hadn't noticed the -n switch that allows you to
> >run it in X (with switching to a VC first).
> >
> >You can still ssh into, and scp to, the machine while it's locked.
> >AFAICT Debian's versions allow unlocking with the root password as
> >well as the user's, which is handy if you forget which username
> >you were logged in under when you vlock'd it.
> >
> > https://lists.debian.org/debian-user/2017/11/msg00951.html
> 
> Thanks David, works great, KDE runs on VC7 I went to VC2 an ran '$
> vlock -a' and I was NOT able to switch to any other VC it was locked
> with the message to press enter with passwd, if you press enter with
> wrong passwd or no passwd you will be prompted for ROOT passwd. For
> me that was no problem, but I can see the shock on someones face
> when they don't know the root passwd and I got a chuckle out of
> that. After entering the root passwd I was able to switch back to
> VC7 and all was well. :)

With nothing available but the Return key, methods of giving you
user/root password choice are limited. The solution is alternation:
just keep pressing the Return key until you get the prompt you want.

Cheers,
David.

Re: Embarrassing security bug in systemd

[David Wright]

On Sun 10 Dec 2017 at 10:42:53 (-0500), Gene Heskett wrote:

> For something that can be such a pita, not installing the docs doesn't 
> seem like my error, they should have been part of the install. IMO.

That's ridiculous. I don't want all the docs on all the installations.
I only install docs on the machines that either I'm going to read it on
or one with a big disk.

Cheers,
David.

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Sunday 10 December 2017 05:33:17 to...@tuxteam.de wrote:

> On Sat, Dec 09, 2017 at 11:29:58AM -0500, Gene Heskett wrote:
> > Thats another very sore point. Where are the man pages? Its
> > installed on 6, maybe 7 machines here, with zero docs.
>
> Not a user of policykit here -- I don't like it (as may be deduced
> from my other posts). But Gene, before getting all impolite on folks
> *giving you stuff for free*, please do some homework. The policykit-1
> package page [1] lists *seven* man pages accompanying the package
> itself:
>
>   /usr/share/man/man1/pkaction.1.gz
>   /usr/share/man/man1/pkcheck.1.gz
>   /usr/share/man/man1/pkexec.1.gz
>   /usr/share/man/man1/pkttyagent.1.gz
>   /usr/share/man/man8/pklocalauthority.8.gz
>   /usr/share/man/man8/polkit.8.gz
>   /usr/share/man/man8/polkitd.8.gz
>
> (and should those be missing in your machines, care to file a bug?)
>
> You read any of them? 

The (pk)localauthority file itself, yes, not particularly helpfull. The 
man page may be better.

> Thought so. 

No, its almost too early, and I've been a type B person for 83 years. And 
I have a bigger problem to tend to first on one of my machines. It s/b 
be an easy fix, but where in 800+ loc?
>
> It took me less than 5 minutes to find that out, even not having
> polkit installed. Install && use it, or... leave it (as I do), but
> stop shitting on people offering you (for free) the fruit of their
> labours.

But you did know enough that it had 2 separate names, a huge help.

> >  What the hell? If debian or
> > any other distro decides to shove this crap down our throats,
>
> My throat is clear, thankyouverymuch. Nothing has been forced this
> way (by Debian, at least).
>
> >  at
> > least have the courtesy of making the docs available. I just
> > searched thru the repo's with synaptic and came up null and empty on
> > polkit-1.
>
> Once you've read that pages above, you also might want install
> policykit-1-doc [2] with (roughly estimated) 50 HTML files carefully
> written for your reading convenience.

Done that install now, thank you. And that's an arm64 card (rock64) 
running stretch, the other problem child is an armhf, a pi3b running 
jessie.

> > So where are the docs?
>
> Do you see them now?
>
> Sorry for the somewhat rough tone. But: (1) your tone was also
> somewhat rough, so par for the course, I'd say. And (2) always
> assume the possibility of an error on your side.
>
For something that can be such a pita, not installing the docs doesn't 
seem like my error, they should have been part of the install. IMO.
I first asked a related question about making synaptic-pkexec work over 
an ssh -Y login at least a year ago. And was ignored then, and at least 
once since.

Sure, I can also use apt, but where then is the list of uninstalled 
files? If you can't see that list, how do you know what might be 
helpfull?

But now that I've managed to upset the right people, and get a helpfull 
answer, I will now tip my hat and say Thank You Very Much.

I did find a synaptic related thing in those /usr/share files a few days 
ago, but without a clue how to change it due to this lack of docs, what 
I tried didn't work so I restored it. Does it need a restart to make the 
edits effective?

Again, thank you very much, this should be helpfull.

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 

Re: Embarrassing security bug in systemd

[Dejan Jocic]

On 10-12-17, Joe wrote:
> On Sun, 10 Dec 2017 11:02:45 +0100
> Dejan Jocic  wrote:
> 
> > On 10-12-17, Joe wrote:
> > > On Sun, 10 Dec 2017 00:13:59 +0100
> > > Dejan Jocic  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

Re: Embarrassing security bug in systemd

[Joe]

On Sun, 10 Dec 2017 11:02:45 +0100
Dejan Jocic  wrote:

> On 10-12-17, Joe wrote:
> > On Sun, 10 Dec 2017 00:13:59 +0100
> > Dejan Jocic  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

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Dec 09, 2017 at 11:29:58AM -0500, Gene Heskett wrote:

> Thats another very sore point. Where are the man pages? Its installed on
> 6, maybe 7 machines here, with zero docs.

Not a user of policykit here -- I don't like it (as may be deduced
from my other posts). But Gene, before getting all impolite on folks
*giving you stuff for free*, please do some homework. The policykit-1
package page [1] lists *seven* man pages accompanying the package
itself:

  /usr/share/man/man1/pkaction.1.gz
  /usr/share/man/man1/pkcheck.1.gz
  /usr/share/man/man1/pkexec.1.gz
  /usr/share/man/man1/pkttyagent.1.gz
  /usr/share/man/man8/pklocalauthority.8.gz
  /usr/share/man/man8/polkit.8.gz
  /usr/share/man/man8/polkitd.8.gz

(and should those be missing in your machines, care to file a bug?)

You read any of them? Thought so.

It took me less than 5 minutes to find that out, even not having
polkit installed. Install && use it, or... leave it (as I do), but
stop shitting on people offering you (for free) the fruit of their
labours.

>  What the hell? If debian or
> any other distro decides to shove this crap down our throats,

My throat is clear, thankyouverymuch. Nothing has been forced this
way (by Debian, at least).

>  at least
> have the courtesy of making the docs available. I just searched thru the
> repo's with synaptic and came up null and empty on polkit-1.

Once you've read that pages above, you also might want install
policykit-1-doc [2] with (roughly estimated) 50 HTML files carefully
written for your reading convenience.

> So where are the docs?

Do you see them now?

Sorry for the somewhat rough tone. But: (1) your tone was also
somewhat rough, so par for the course, I'd say. And (2) always
assume the possibility of an error on your side.

Cheers, nevertheless :-)

[1] https://packages.debian.org/stretch/amd64/policykit-1/filelist
(replace "amd64" by your installed arch)
[2] https://packages.debian.org/stretch/all/policykit-1-doc/filelist

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlotDW0ACgkQBcgs9XrR2kb2agCdHI/ELt0AeC0mBKBBjdfItMsB
AgQAn02vtmOtnwmniVGMh1J57c0iphLs
=7MEz
-END PGP SIGNATURE-

Re: Embarrassing security bug in systemd

[Dejan Jocic]

On 10-12-17, Joe wrote:
> On Sun, 10 Dec 2017 00:13:59 +0100
> Dejan Jocic  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?

Re: Embarrassing security bug in systemd

[Joe]

On Sun, 10 Dec 2017 00:13:59 +0100
Dejan Jocic  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 

Re: Embarrassing security bug in systemd

[Jimmy Johnson]

On 12/09/2017 08:23 AM, David Wright wrote:

On Fri 08 Dec 2017 at 18:30:08 (-0800), Jimmy Johnson wrote:

On 12/07/2017 02:31 AM, Jonathan Dowland wrote:

On Thu, Dec 07, 2017 at 10:02:56AM +, Tixy wrote:

I'm running Jessie (with systemd running but booting with sysvinit) and
trying to execute halt/poweroff/reboot/shutdown from a terminal without
root privileges gives an error saying I must be superuser. Which has
always been my experience in 10 years of using Debian.


Be careful to double check what you are testing: in your situation it's
not clear whether /sbin/reboot is a symlink to systemctl (part of
systemd, so I would expect this not to work if you were not running
systemd as the init system) or a separate binary.



Jonathan, I started thinking about lost work where someone restarted
the computer while I was away from it and thought what if you can
lock-screen and lock access to console at the same time.  Is that
something that could be done? Helpful?

I know someone can pull the cord or press the power button, I got past that.


I use vlock -a in a VC to lock all the consoles. I've been using
it for years so I hadn't noticed the -n switch that allows you to
run it in X (with switching to a VC first).

You can still ssh into, and scp to, the machine while it's locked.
AFAICT Debian's versions allow unlocking with the root password as
well as the user's, which is handy if you forget which username
you were logged in under when you vlock'd it.

 https://lists.debian.org/debian-user/2017/11/msg00951.html


Thanks David, works great, KDE runs on VC7 I went to VC2 an ran '$ vlock 
-a' and I was NOT able to switch to any other VC it was locked with the 
message to press enter with passwd, if you press enter with wrong passwd 
or no passwd you will be prompted for ROOT passwd. For me that was no 
problem, but I can see the shock on someones face when they don't know 
the root passwd and I got a chuckle out of that. After entering the root 
passwd I was able to switch back to VC7 and all was well. :)


Cheers!
--
Jimmy Johnson

Debian Buster - KDE Plasma 5.10.5 - AMD A8-7600 - EXT4 at sda7
Registered Linux User #380263

Re: Embarrassing security bug in systemd

[The Wanderer]

On 2017-12-09 at 09:10, Brian wrote:

> The Terms and Conditions of installing a Debian package include (as 
> I'm sure you are aware) accepting the Depends: and Recomends: lines. 
> What is in these lines can be accepted or rejected and, in the case 
> of Recommends:, adjusted to suit your needs. Installing the package 
> necessarily involves making an explicit request for other packages.

No, it doesn't. That's the exact distinction between "explicit" and
"implicit".

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Embarrassing security bug in systemd

[Dejan Jocic]

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 +, 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-23e274a0b...@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

Re: Embarrassing security bug in systemd

[Ben Caradoc-Davies]

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 
Director
Transient Software Limited 
New Zealand

Re: Embarrassing security bug in systemd

[Brian]

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 +, 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-23e274a0b...@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.

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Saturday 09 December 2017 12:01:59 David Wright wrote:

> On Sat 09 Dec 2017 at 11:29:58 (-0500), Gene Heskett wrote:
> > On Saturday 09 December 2017 05:12:16 Joe wrote:
> > > On Fri, 8 Dec 2017 23:56:44 +
> > >
> > > Brian  wrote:
> > > > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> > > > > On Fri, 8 Dec 2017 17:12:18 -0500
> > > > >
> > > > > Cindy-Sue Causey  wrote:
> > > > > > I do remember having to give a password, but I don't
> > > > > > remember how long ago now. And I have too much open right
> > > > > > now to test drive whether mine does it or not these days..
> > > > > > :)
> > > > >
> > > > > As I did the other day. I've tried it now (up-to-date
> > > > > unstable) and it works for a non-root user.
> > > >
> > > > Without policykit-1 installed it doesn't; no rebooting or
> > > > powering off with /sbin/reboot or /sbin/poweroff for a user.
> > > > CTRL+ALT+DEL from a terminal reboots. That's the same behaviour
> > > > as sysvinit.
> > >
> > > Yes, I understand that, the point is that the first installation
> > > of policykit-1, which I did not explicitly request, did not ask me
> > > if I wanted non-root users to be able to reboot, or indeed about
> > > anything else it might control. Not that it matters on any of my
> > > machines, I'd just like to have been told that it was changing,
> > > and given the option to keep it as it was had I needed to.
> >
> > Thats another very sore point. Where are the man pages? Its
> > installed on 6, maybe 7 machines here, with zero docs. What the
> > hell? If debian or any other distro decides to shove this crap down
> > our throats, at least have the courtesy of making the docs
> > available. I just searched thru the repo's with synaptic and came up
> > null and empty on polkit-1.
> >
> > So where are the docs?
>
> $ dpkg -L policykit-1 | less
> will reveal what came with the package, and you'll find the
> manpages listed there, about 7 of them.
>
> Cheers,
> David.

I see that David, but when the name is not consistent, it comes across as 
yet another attempt to keep it all a secret from those not in the know, 
but are just harassed to tears by the effects of this stuff.

In case you hadn't noticed, polkit-1 /= policykit-1 when doing a search. 
So lets at least have a consistent name, and a lot of the fire and name 
calling will go away simply because we CAN find the docs. And if the 
deocs are complete enough, maybe even fix our bitches.

As it exists now, the miss-matched names are seen as nothing but 
obfuscation, purposely designed to prevent the users from over-riding 
its ill-formed (to us who have been running an all linux house for the 
last 19 years, and used Amiga's for a decade before that) rules choices. 
Linux is supposedly all about freedom of choice, so give it back to us 
instead of having to constantly feed the flame war just to get the info 
we need, which is as you are well aware, difficult to do without making 
some enemies.

Thank you David, for emitting that bit of information and helping the 
rest of us. 

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 

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Sat, Dec 09, 2017 at 06:20:01PM +, Jonathan Dowland wrote:
> On Sat, 2017-12-09 at 10:00 +, 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

Re: Embarrassing security bug in systemd

[Brian]

On Sat 09 Dec 2017 at 18:20:01 +, Jonathan Dowland wrote:

> On Sat, 2017-12-09 at 10:00 +, 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.

Re: Embarrassing security bug in systemd

[Dejan Jocic]

On 09-12-17, Jonathan Dowland wrote:
> On Sat, 2017-12-09 at 10:00 +, 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-23e274a0b...@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

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

On Sat, 2017-12-09 at 10:00 +, 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-23e274a0b...@debian.org>

Re: Embarrassing security bug in systemd

[David Wright]

On Sat 09 Dec 2017 at 11:29:58 (-0500), Gene Heskett wrote:
> On Saturday 09 December 2017 05:12:16 Joe wrote:
> 
> > On Fri, 8 Dec 2017 23:56:44 +
> >
> > Brian  wrote:
> > > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> > > > On Fri, 8 Dec 2017 17:12:18 -0500
> > > >
> > > > Cindy-Sue Causey  wrote:
> > > > > I do remember having to give a password, but I don't remember
> > > > > how long ago now. And I have too much open right now to test
> > > > > drive whether mine does it or not these days.. :)
> > > >
> > > > As I did the other day. I've tried it now (up-to-date unstable)
> > > > and it works for a non-root user.
> > >
> > > Without policykit-1 installed it doesn't; no rebooting or powering
> > > off with /sbin/reboot or /sbin/poweroff for a user. CTRL+ALT+DEL
> > > from a terminal reboots. That's the same behaviour as sysvinit.
> >
> > Yes, I understand that, the point is that the first installation of
> > policykit-1, which I did not explicitly request, did not ask me if I
> > wanted non-root users to be able to reboot, or indeed about anything
> > else it might control. Not that it matters on any of my machines, I'd
> > just like to have been told that it was changing, and given the option
> > to keep it as it was had I needed to.
> 
> Thats another very sore point. Where are the man pages? Its installed on 
> 6, maybe 7 machines here, with zero docs. What the hell? If debian or 
> any other distro decides to shove this crap down our throats, at least 
> have the courtesy of making the docs available. I just searched thru the 
> repo's with synaptic and came up null and empty on polkit-1.
> 
> So where are the docs?

$ dpkg -L policykit-1 | less
will reveal what came with the package, and you'll find the
manpages listed there, about 7 of them.

Cheers,
David.

Re: Embarrassing security bug in systemd

[David Wright]

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.

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Saturday 09 December 2017 05:12:16 Joe wrote:

> On Fri, 8 Dec 2017 23:56:44 +
>
> Brian  wrote:
> > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> > > On Fri, 8 Dec 2017 17:12:18 -0500
> > >
> > > Cindy-Sue Causey  wrote:
> > > > I do remember having to give a password, but I don't remember
> > > > how long ago now. And I have too much open right now to test
> > > > drive whether mine does it or not these days.. :)
> > >
> > > As I did the other day. I've tried it now (up-to-date unstable)
> > > and it works for a non-root user.
> >
> > Without policykit-1 installed it doesn't; no rebooting or powering
> > off with /sbin/reboot or /sbin/poweroff for a user. CTRL+ALT+DEL
> > from a terminal reboots. That's the same behaviour as sysvinit.
>
> Yes, I understand that, the point is that the first installation of
> policykit-1, which I did not explicitly request, did not ask me if I
> wanted non-root users to be able to reboot, or indeed about anything
> else it might control. Not that it matters on any of my machines, I'd
> just like to have been told that it was changing, and given the option
> to keep it as it was had I needed to.

Thats another very sore point. Where are the man pages? Its installed on 
6, maybe 7 machines here, with zero docs. What the hell? If debian or 
any other distro decides to shove this crap down our throats, at least 
have the courtesy of making the docs available. I just searched thru the 
repo's with synaptic and came up null and empty on polkit-1.

So where are the docs?

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 

Re: Embarrassing security bug in systemd

[David Wright]

On Fri 08 Dec 2017 at 18:30:08 (-0800), Jimmy Johnson wrote:
> On 12/07/2017 02:31 AM, Jonathan Dowland wrote:
> >On Thu, Dec 07, 2017 at 10:02:56AM +, Tixy wrote:
> >>I'm running Jessie (with systemd running but booting with sysvinit) and
> >>trying to execute halt/poweroff/reboot/shutdown from a terminal without
> >>root privileges gives an error saying I must be superuser. Which has
> >>always been my experience in 10 years of using Debian.
> >
> >Be careful to double check what you are testing: in your situation it's
> >not clear whether /sbin/reboot is a symlink to systemctl (part of
> >systemd, so I would expect this not to work if you were not running
> >systemd as the init system) or a separate binary.
> 
> 
> Jonathan, I started thinking about lost work where someone restarted
> the computer while I was away from it and thought what if you can
> lock-screen and lock access to console at the same time.  Is that
> something that could be done? Helpful?
> 
> I know someone can pull the cord or press the power button, I got past that.

I use vlock -a in a VC to lock all the consoles. I've been using
it for years so I hadn't noticed the -n switch that allows you to
run it in X (with switching to a VC first).

You can still ssh into, and scp to, the machine while it's locked.
AFAICT Debian's versions allow unlocking with the root password as
well as the user's, which is handy if you forget which username
you were logged in under when you vlock'd it.

https://lists.debian.org/debian-user/2017/11/msg00951.html

Cheers,
David.

Re: Embarrassing security bug in systemd

[Tom Furie]

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.


signature.asc
Description: Digital signature

Re: Embarrassing security bug in systemd

[Ric Moore]

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

Re: Embarrassing security bug in systemd

[Brian]

On Sat 09 Dec 2017 at 10:12:16 +, Joe wrote:

> On Fri, 8 Dec 2017 23:56:44 +
> Brian  wrote:
> 
> > On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> > 
> > > On Fri, 8 Dec 2017 17:12:18 -0500
> > > Cindy-Sue Causey  wrote:
> > >   
> > > > 
> > > > I do remember having to give a password, but I don't remember how
> > > > long ago now. And I have too much open right now to test drive
> > > > whether mine does it or not these days.. :)
> > > >   
> > > As I did the other day. I've tried it now (up-to-date unstable) and
> > > it works for a non-root user.  
> > 
> > Without policykit-1 installed it doesn't; no rebooting or powering
> > off with /sbin/reboot or /sbin/poweroff for a user. CTRL+ALT+DEL
> > from a terminal reboots. That's the same behaviour as sysvinit.
> > 
> 
> Yes, I understand that, the point is that the first installation of
> policykit-1, which I did not explicitly request, did not ask me if I
> wanted non-root users to be able to reboot, or indeed about anything
> else it might control. Not that it matters on any of my machines, I'd
> just like to have been told that it was changing, and given the option
> to keep it as it was had I needed to.

The Terms and Conditions of installing a Debian package include (as
I'm sure you are aware) accepting the Depends: and Recomends: lines.
What is in these lines can be accepted or rejected and, in the case
of Recommends:, adjusted to suit your needs. Installing the package
necessarily involves making an explicit request for other packages.

Being asked about choices on installing policykit would probably have
involved a patch for the package and a debconf notice informing users
about this and other changes over previous system behaviour. Apart
from the notice perhaps getting involved, the option to keep previous
behaviour would be of no importance to new users.

-- 
Brian.

Re: Embarrassing security bug in systemd

[Joe]

On Fri, 8 Dec 2017 23:56:44 +
Brian  wrote:

> On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:
> 
> > On Fri, 8 Dec 2017 17:12:18 -0500
> > Cindy-Sue Causey  wrote:
> >   
> > > 
> > > I do remember having to give a password, but I don't remember how
> > > long ago now. And I have too much open right now to test drive
> > > whether mine does it or not these days.. :)
> > >   
> > As I did the other day. I've tried it now (up-to-date unstable) and
> > it works for a non-root user.  
> 
> Without policykit-1 installed it doesn't; no rebooting or powering
> off with /sbin/reboot or /sbin/poweroff for a user. CTRL+ALT+DEL
> from a terminal reboots. That's the same behaviour as sysvinit.
> 

Yes, I understand that, the point is that the first installation of
policykit-1, which I did not explicitly request, did not ask me if I
wanted non-root users to be able to reboot, or indeed about anything
else it might control. Not that it matters on any of my machines, I'd
just like to have been told that it was changing, and given the option
to keep it as it was had I needed to.

-- 
Joe

Re: Embarrassing security bug in systemd

[Brian]

On Sat 09 Dec 2017 at 07:52:56 +, Jonathan Dowland wrote:

> On Fri, Dec 08, 2017 at 07:57:03PM +, 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.

Re: Embarrassing security bug in systemd

[Joe]

On Sat, 09 Dec 2017 01:46:59 +
Mark Fletcher  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

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Dec 08, 2017 at 05:04:51PM -0600, John Hasler wrote:
> tomas writes:
> > Not a fan of systemd here (have outed myself this way clearly enough,
> > I think), but systemd is pretty well documented, for sure.
> 
> Is the Debian default configuration of Systemd also well documented?

This enough for you?

  https://wiki.debian.org/systemd

Try a search on that wiki:

  
https://wiki.debian.org/FrontPage?action=fullsearch=180=systemd=Titles

or similar. No, lack of documentation is not something
you could blame onto systemd (or its surroundings).

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlorn+wACgkQBcgs9XrR2kaUVACfRP1XGRnK4J4IYKCT+rP6K8JA
XcIAn1d+xRcIhp1VSVA4A6LcZEU/t1W9
=S08x
-END PGP SIGNATURE-

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

On Sat, Dec 09, 2017 at 01:30:17AM +, Glenn English wrote:

Even if there's an error in the release note? Less than optimal way to
run a train.


Errors and omissions are different things. I'm not responsible for
release notes but I suspect if there was something that was glaringly
false, it *could* be changed. Let me know if you find one.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

On Fri, Dec 08, 2017 at 03:31:54PM -0500, Gene Heskett wrote:

On Friday 08 December 2017 14:26:41 Jonathan Dowland wrote:

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.


Release notes and manual pages are completely different things. The
systemd manual pages are pretty good, IMHO. But If you'd like to point
out specific omissions, they might get fixed.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

On Fri, Dec 08, 2017 at 07:57:03PM +, 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.

Re: Embarrassing security bug in systemd

[John Hasler]

Glenn writes:
> Even if there's an error in the release note? Less than optimal way to
> run a train.

You can't retroactively fix the release notes: they are part of the
already released release.  All you can do is publish an errata and
correct the error in the next point release.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Embarrassing security bug in systemd

[Jimmy Johnson]

On 12/07/2017 02:31 AM, Jonathan Dowland wrote:

On Thu, Dec 07, 2017 at 10:02:56AM +, Tixy wrote:

I'm running Jessie (with systemd running but booting with sysvinit) and
trying to execute halt/poweroff/reboot/shutdown from a terminal without
root privileges gives an error saying I must be superuser. Which has
always been my experience in 10 years of using Debian.


Be careful to double check what you are testing: in your situation it's
not clear whether /sbin/reboot is a symlink to systemctl (part of
systemd, so I would expect this not to work if you were not running
systemd as the init system) or a separate binary.



Jonathan, I started thinking about lost work where someone restarted the 
computer while I was away from it and thought what if you can 
lock-screen and lock access to console at the same time.  Is that 
something that could be done? Helpful?


I know someone can pull the cord or press the power button, I got past that.
--
Jimmy Johnson

Debian Buster - KDE Plasma 5.10.5 - AMD A8-7600 - EXT4 at sda7
Registered Linux User #380263

Re: Embarrassing security bug in systemd

[Mark Fletcher]

The OP has never been seen again since the original post. Just sayin’...

On Sat, Dec 9, 2017 at 9:39 Menelaos Maglis  wrote:

> Joe  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.
>
>
>

Re: Embarrassing security bug in systemd

[Glenn English]

On Fri, Dec 8, 2017 at 9:07 PM, John Hasler  wrote:
> Gene Heskitt writes:

>> So now, no effort will ever be made to fix the man pages. Hell of a
>> way to run a train.
>
> That doesn't follow.  The release note are specific to the release and
> thus obviously cannot be fixed.

Even if there's an error in the release note? Less than optimal way to
run a train.

--
Glenn English

Re: Embarrassing security bug in systemd

[Menelaos Maglis]

Joe  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.

Re: Embarrassing security bug in systemd

[Brian]

On Fri 08 Dec 2017 at 23:06:00 +, Joe wrote:

> On Fri, 8 Dec 2017 17:12:18 -0500
> Cindy-Sue Causey  wrote:
> 
> > 
> > I do remember having to give a password, but I don't remember how long
> > ago now. And I have too much open right now to test drive whether mine
> > does it or not these days.. :)
> > 
> As I did the other day. I've tried it now (up-to-date unstable) and it
> works for a non-root user.

Without policykit-1 installed it doesn't; no rebooting or powering
off with /sbin/reboot or /sbin/poweroff for a user. CTRL+ALT+DEL
from a terminal reboots. That's the same behaviour as sysvinit.

-- 
Brian.

Re: Embarrassing security bug in systemd

[John Hasler]

tomas writes:
> Not a fan of systemd here (have outed myself this way clearly enough,
> I think), but systemd is pretty well documented, for sure.

Is the Debian default configuration of Systemd also well documented?
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Embarrassing security bug in systemd

[Joe]

On Fri, 8 Dec 2017 17:12:18 -0500
Cindy-Sue Causey  wrote:

> 
> I do remember having to give a password, but I don't remember how long
> ago now. And I have too much open right now to test drive whether mine
> does it or not these days.. :)
> 
As I did the other day. I've tried it now (up-to-date unstable) and it
works for a non-root user.

> I do understand everyone's rationale for why they like or dislike
> either way. 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.
> 
Yes, it's not so much *what* happens, as how it's different now than it
was, and how few regular Debian users seemed to know about it. Only the
developers seemed to be aware of the issue. As I said, I do glance
through changelogs to look for real gotchas that affect me (not really
many of them) and I don't recall seeing a warning about this. And it
*should* have been a warning, not just a tiny footnote, because it's a
[small] security measure being turned off by default. That shouldn't
happen during an upgrade without a reasonable attempt to warn users.

> I think I finally came to the (potentially misguided) a-sumption that
> one rationale *might* have something to do with having to sit here in
> person to click the GUI's menu path but maybe not for the terminal
> and/or other (?) hackable routes... :)

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. We are
asked about root/non-root permission for the man pages.

-- 
Joe

Re: Embarrassing security bug in systemd

[Cindy-Sue Causey]

On 12/7/17, Dave Sherohman  wrote:
> On Thu, Dec 07, 2017 at 11:26:45AM +1300, Ben Caradoc-Davies wrote:
>> Special privileges have been granted to console users for as long as I
>> can
>> remember, long before systemd, because they have physical access to the
>> machine. Console users typically are also permitted to mount, unmount,
>> and
>> eject removable media, and have access to audio devices.
>
> I think this is a key point that's been overlooked in the complaints
> about this behavior:  It has nothing to do with systemd.
>
> I no longer have any non-systemd machines handy to verify this on, but
> my memory is that I have *always* been able to use halt/poweroff/reboot
> commands from the console without requiring sudo or entering a password,
> and I've been using Debian since 2000ish, well before systemd was even a
> gleam in some programmer's eye.  /sbin/shutdown may have also been
> freely available at the console, but I don't remember that one clearly,
> since I didn't use it all that often once I discovered the others.
>
> But, then, even if I'm remembering incorrectly, it's still a policy
> matter, not a technical one.  If the policy was changed at the same time
> as Debian switched to systemd, that's just a coincidence of timing and
> the same policy change could have happened while still under sysvinit.


I do remember having to give a password, but I don't remember how long
ago now. And I have too much open right now to test drive whether mine
does it or not these days.. :)

I do understand everyone's rationale for why they like or dislike
either way. 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.

I think I finally came to the (potentially misguided) a-sumption that
one rationale *might* have something to do with having to sit here in
person to click the GUI's menu path but maybe not for the terminal
and/or other (?) hackable routes... :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Dec 08, 2017 at 03:29:20PM -0500, Gene Heskett wrote:

[...]

> Which until now I have never seen its supposed advantages touted. Maybe I 
> don't subscribe to the right lists?

Hey, to each her/his own...

> rant mode on!
> 
> Couldn't a lot of the hatred for systemd have been avoided if it was 
> adequately discussed/described in the first place? Had it been 
> accompanied by an adequate description, and a clear but concise man 
> page, including how to change it if you didn't like the defaults, would 
> have made this take it or go run windows attitude a hell of a lot easier 
> to accept.

Not a fan of systemd here (have outed myself this way clearly enough,
I think), but systemd is pretty well documented, for sure.

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlorAPMACgkQBcgs9XrR2kaDVQCfUmnXy+HjVf1NoY9Y0LCrpPVq
Q+AAn1Uz2NPvP8b6Thtji4baOBh4uSNB
=EdQz
-END PGP SIGNATURE-

Re: Embarrassing security bug in systemd

[John Hasler]

Gene Heskitt writes:
> So now, no effort will ever be made to fix the man pages. Hell of a
> way to run a train.

That doesn't follow.  The release note are specific to the release and
thus obviously cannot be fixed.  The man pages can be fixed in any
future release of the subject packages.  File bug reports against the
relevant packages explaining what you think needs to change.  Mention
the man pages in the bug title.  If the bug is closed without action or
marked "won'tfix" (or ignored) then you will have reason to gripe.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Embarrassing security bug in systemd

[Gene Heskett]

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 

Re: Embarrassing security bug in systemd

[Gene Heskett]

On Friday 08 December 2017 13:09:06 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.

Which until now I have never seen its supposed advantages touted. Maybe I 
don't subscribe to the right lists?

rant mode on!

Couldn't a lot of the hatred for systemd have been avoided if it was 
adequately discussed/described in the first place? Had it been 
accompanied by an adequate description, and a clear but concise man 
page, including how to change it if you didn't like the defaults, would 
have made this take it or go run windows attitude a hell of a lot easier 
to accept.

I can say the same for pam. I just read the man page for the umptyieth 
time, but not a single character was devoted to how to change its 
behavior, and its blocking me from doing things on jessie or stretch 
that were/are Just Doable on wheezy. synaptics-pkexec for instance, 
absolutely no reason I am denied that for jessie and stretch, but in 
both cases I am forced to do it from the machines own keyboard even if 
most any other gfx using program can be run from here over an ssh -Y 
login. On a home network thats behind a firewall that has not been 
penetrated in 15 years, such restrictions are the same stuff usually 
found on the ground behind the male of the bovine specie.

I have previously asked how to fix that, and been /universally/ ignored. 
So where do I find out how to fix that?

> In anycase, it should be a documented configuration option to allow
> for alternative use cases.

A universal wish I suspect. But it seems to be a bigger secret than the 
winderz 10 source code.

I am not a migrant from the M$ camp, so quit treating me like one. The 
ONLY machine I own that ever had windows on it, because 12 years ago if 
you wanted a portable "lappy" you could take on the road when playing 
visiting fireman at some broadcast facility that had technical fires to 
be put out, you bought it with xp on it. But xp got nuked for mandrake 
after I spent a week or more trying to make the windows driver actually 
work with a bcm4318 radio it had. But netgear sells several usb dongles 
that just work with linux.

/rant off
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 

Re: Embarrassing security bug in systemd

[deloptes]

to...@tuxteam.de wrote:

> Now watch all the old skoolers dashing out of their little caves and
> waving their fists at something which could be read as a provocation
> (I'm myself one of those, just look a bit upthread :)
> 

It is not about old or new, but about known and unknown. Unkown exposes me
to risk. As also highlighted here the solution is not the best on multiuser
environment, but I think one could configure systemd to respect the
requirements.
I first accepted systemd also advocated for "progress", but after a long
discussion here (at least 6months ago) I revisited my opinion and installed
sysvinit first on the server and then on the desktop, notebook etc.

> In the sense of civilized discourse, I now do a bit of introspection
> and think one could read Michael's statement differently. For those
> using the computers "classically", there was no mess. Issue su at
> any console (most of us did the migration to sudo a while ago, since
> it's more convenient and a tad safer), done. No mess.
> 

This is true and I think we'll find time to learn systemd and get
comfortable with that.

> But for a desktop environment, which has been silently permeated
> by the assumption "one computer -- one user -- one display/keyboard"
> and which wants to offer their users transparent access to system
> management tasks (install printer, package system, video resolution,
> yadda yadda) in a way that looks somewhat like Those Other Operating
> Systems, the implementations we have seen are a mess, all this
> Gnome *kit horror and whatever KDE does (there's enough mess still
> left: why have Gnome and KDE to invent their own virtual file
> systems? Have you ever had a look at what Gnome does to attach
> emblems to files? And so on).
> 

This is also true - gnome went insane and KDE unusable as of v4.

> So I understand perfectly that those desktop environments have
> clinged desperately to systemd. They are constantly on the brink
> of breaking down under their own complexity, so exporting some
> of it to Some Other Place always feels like a bit of fresh air.
> 
> So in this context, I'd say Michael is spot on.
> 
> Now if you don't buy into that desktop thing, systemd doesn't
> look like a simplification or sorting out some mess, I'd think.
> But some agree to differ on that too.

For me personally systemd is very new and I need to find time to understand
it and be able to manage it.

Re: Embarrassing security bug in systemd

[Brian]

On Fri 08 Dec 2017 at 19: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.

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.

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

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.

Re: Embarrassing security bug in systemd

[deloptes]

Roberto C. Sánchez wrote:

> That is really the problem that I have with this while issue that was
> brought up.  I get that it is a "sensible" default to allow users on the
> console (TTY or via DM) permission to reboot the machine.  However, when
> an admin has configured the system to disallow that sort of thing, it is
> frustrating to have a new thing come along and not respect the
> configuration.  It is even more frustrating when the fact that the new
> thing ignores the configuration is not even documented where one would
> expect it (i.e., the Debian release notes in this case).

This is also my problem with systemd and the main reason to either deny it
or use it with caution.
This is also typical to some of the developers standing behind it. Which is
one more reason

regards

Re: Embarrassing security bug in systemd

[Menelaos Maglis]

>> > 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.

Re: Embarrassing security bug in systemd

[Menelaos Maglis]

>> > 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.

Re: Embarrassing security bug in systemd

[Curt]

On 2017-12-08, Jonathan Dowland  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

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

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

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Dec 08, 2017 at 12:17:16PM +0100, deloptes wrote:
> Michael Biebl wrote:
> 
> > Basically, it was a completely inconsistent mess before systemd.
[...]

> 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 [...]

Now watch all the old skoolers dashing out of their little caves and
waving their fists at something which could be read as a provocation
(I'm myself one of those, just look a bit upthread :)

In the sense of civilized discourse, I now do a bit of introspection
and think one could read Michael's statement differently. For those
using the computers "classically", there was no mess. Issue su at
any console (most of us did the migration to sudo a while ago, since
it's more convenient and a tad safer), done. No mess.

But for a desktop environment, which has been silently permeated
by the assumption "one computer -- one user -- one display/keyboard"
and which wants to offer their users transparent access to system
management tasks (install printer, package system, video resolution,
yadda yadda) in a way that looks somewhat like Those Other Operating
Systems, the implementations we have seen *are* a mess, all this
Gnome *kit horror and whatever KDE does (there's enough mess still
left: why have Gnome and KDE to invent their own virtual file
systems? Have you ever had a look at what Gnome does to attach
emblems to files? And so on).

So I understand perfectly that those desktop environments have
clinged desperately to systemd. They are constantly on the brink
of breaking down under their own complexity, so exporting some
of it to Some Other Place always feels like a bit of fresh air.

So in *this* context, I'd say Michael is spot on.

Now if you don't buy into that desktop thing, systemd doesn't
look like a simplification or sorting out some mess, I'd think.
But some agree to differ on that too.

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAloqgaYACgkQBcgs9XrR2kaO/wCfbozo+GxKHs6LchrMG0roUDo1
pVsAnRUpDXw/leYTb3VF541aJZHw4Q6K
=Ligm
-END PGP SIGNATURE-

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Fri, Dec 08, 2017 at 10:17:36AM +0100, Menelaos Maglis wrote:
> 
> It is an improvement to have a consistent (central) way to configure
> this behavior.
> 
> It is probably a "good thing" to allow users with physical access to
> reboot/shutdown a desktop/laptop system.
> 
> It is probably not a preferred solution for a multi-user/server system.
> 
It is a definitely a bad thing to silently change/break an existing
configuration.

That is really the problem that I have with this while issue that was
brought up.  I get that it is a "sensible" default to allow users on the
console (TTY or via DM) permission to reboot the machine.  However, when
an admin has configured the system to disallow that sort of thing, it is
frustrating to have a new thing come along and not respect the
configuration.  It is even more frustrating when the fact that the new
thing ignores the configuration is not even documented where one would
expect it (i.e., the Debian release notes in this case).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[deloptes]

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.

regards

Re: Embarrassing security bug in systemd

[Menelaos Maglis]

>>> 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
>
> 
>   auth_admin_keep
>   auth_admin_keep
>   yes
> 
>
> 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.

It is an improvement to have a consistent (central) way to configure
this behavior.

It is probably a "good thing" to allow users with physical access to
reboot/shutdown a desktop/laptop system.

It is probably not a preferred solution for a multi-user/server system.

One user group can say to the other "go an change the default policy",
or the installer can pick the "the right thing to do" based on the
installation profile...

Regards,
Menelaos Maglis

Re: Embarrassing security bug in systemd

[Dave Sherohman]

On Thu, Dec 07, 2017 at 09:37:25AM -0500, Roberto C. Sánchez wrote:
> On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote:
> > 
> > I no longer have any non-systemd machines handy to verify this on, but
> > my memory is that I have *always* been able to use halt/poweroff/reboot
> > commands from the console without requiring sudo or entering a password,
> > and I've been using Debian since 2000ish, well before systemd was even a
> > gleam in some programmer's eye.  /sbin/shutdown may have also been
> > freely available at the console, but I don't remember that one clearly,
> > since I didn't use it all that often once I discovered the others.
> > 
> I just did a fresh install of wheezy (7.11) with all defaults.  Here is
> what happened:
> 
> testuser@debian:~$ cat /etc/debian_version
> 7.11
> testuser@debian:~$ /sbin/reboot
> reboot: must be superuser.
> testuser@debian:~$ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 4 Jul 14  2013 /sbin/reboot -> halt
> testuser@debian:~$ ls -l /sbin/halt
> -rwxr-xr-x 1 root root 15184 Jul 14  2013 /sbin/halt
> 
> The situation is basically the same for /sbin/shutdown.

Well, then.  I stand corrected.  Thanks for reminding me of what I'd
forgotten!

-- 
Dave Sherohman

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Dec 07, 2017 at 08:03:47PM +0100, 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.

Hey, I'm "before systemd" (and plan to stay so). I disagree that
I'm an inconsistent mess (yes, a bit tongue-in-cheek ;-P

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAloqRxQACgkQBcgs9XrR2kbLiQCeKvl/VX1lALeAA3a0OcCewZae
4c8AnR3qyJ01Pq/Hv18rbfrbpO3qWtMM
=GJwl
-END PGP SIGNATURE-

Re: Embarrassing security bug in systemd

[Michael Biebl]

Am 07.12.2017 um 15:37 schrieb Roberto C. Sánchez:
> On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote:
>>
>> I no longer have any non-systemd machines handy to verify this on, but
>> my memory is that I have *always* been able to use halt/poweroff/reboot
>> commands from the console without requiring sudo or entering a password,
>> and I've been using Debian since 2000ish, well before systemd was even a
>> gleam in some programmer's eye.  /sbin/shutdown may have also been
>> freely available at the console, but I don't remember that one clearly,
>> since I didn't use it all that often once I discovered the others.
>>
> I just did a fresh install of wheezy (7.11) with all defaults.  Here is
> what happened:
> 
> testuser@debian:~$ cat /etc/debian_version
> 7.11
> testuser@debian:~$ /sbin/reboot
> reboot: must be superuser.
> testuser@debian:~$ ls -l /sbin/reboot
> lrwxrwxrwx 1 root root 4 Jul 14  2013 /sbin/reboot -> halt
> testuser@debian:~$ ls -l /sbin/halt
> -rwxr-xr-x 1 root root 15184 Jul 14  2013 /sbin/halt
> 
> The situation is basically the same for /sbin/shutdown.

Now try CTRL+ALT+DEL on the console. This will reboot your system.
See /etc/inittab:

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now


Next, try hitting the power button. This will shut down your system.
On systems with acpi support, Debian has been installing acpid +
acpi-support-base in the past. See
/etc/acpi/powerbtn-acpi-support.sh


Next install a display manager, like gdm3 or lightdm. This will allow
you shutdown/reboot the system as well.


Basically, it was a completely inconsistent mess before systemd.
Now you at least have a central place where you can configure your
system behaviour.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Embarrassing security bug in systemd

[Roberto C . Sánchez]

On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote:
> 
> I no longer have any non-systemd machines handy to verify this on, but
> my memory is that I have *always* been able to use halt/poweroff/reboot
> commands from the console without requiring sudo or entering a password,
> and I've been using Debian since 2000ish, well before systemd was even a
> gleam in some programmer's eye.  /sbin/shutdown may have also been
> freely available at the console, but I don't remember that one clearly,
> since I didn't use it all that often once I discovered the others.
> 
I just did a fresh install of wheezy (7.11) with all defaults.  Here is
what happened:

testuser@debian:~$ cat /etc/debian_version
7.11
testuser@debian:~$ /sbin/reboot
reboot: must be superuser.
testuser@debian:~$ ls -l /sbin/reboot
lrwxrwxrwx 1 root root 4 Jul 14  2013 /sbin/reboot -> halt
testuser@debian:~$ ls -l /sbin/halt
-rwxr-xr-x 1 root root 15184 Jul 14  2013 /sbin/halt

The situation is basically the same for /sbin/shutdown.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Embarrassing security bug in systemd

[Jonathan Dowland]

On Thu, Dec 07, 2017 at 10:02:56AM +, Tixy wrote:

I'm running Jessie (with systemd running but booting with sysvinit) and
trying to execute halt/poweroff/reboot/shutdown from a terminal without
root privileges gives an error saying I must be superuser. Which has
always been my experience in 10 years of using Debian.


Be careful to double check what you are testing: in your situation it's
not clear whether /sbin/reboot is a symlink to systemctl (part of
systemd, so I would expect this not to work if you were not running
systemd as the init system) or a separate binary.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Embarrassing security bug in systemd

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote:
> On Thu, Dec 07, 2017 at 11:26:45AM +1300, Ben Caradoc-Davies wrote:
> > Special privileges have been granted to console users for as long as I can
> > remember, long before systemd, because they have physical access to the
> > machine. Console users typically are also permitted to mount, unmount, and
> > eject removable media, and have access to audio devices.
> 
> I think this is a key point that's been overlooked in the complaints
> about this behavior:  It has nothing to do with systemd.

No. It has to do with polkit & friends. On my system (which is a pretty
"classic" setup: no systemd, but also as little as possible from all
this more "modern" desktop stuff, which I don't like very much [1]),
/sbin/halt *wants* me to be root. This isn't inherently more secure
(or less) but just The Way it Is (TM) -- an heritage from times *every*
user on an Unix system was remote.

The policy kit and its descendants try to make a guess whether the
user is "physically present" to allow them to shut down the computer.
As others have pointed out, this does make sense (as long as the
above guess is sufficiently accurate, that is), because the user
can pull the cord/extract the batteries/smash the box anyway.

Now to that guess: for your vanilla PC/laptop/tablet/smartphone
class of machine, if the user is at the console or the local
terminal, implying presence is a pretty accurate guess. That's
why the default configuration comes shipped as it is. If you
are installing an ATM/voting computer/AS400, I'd hope that, as
a system integrator you *know what you are doing* and set the
defaults appropriately.

So all is well. This isn't a bug. For someone coming from
"traditional" Unix, this might be unexpected (and has thus some
potential for damage), but that expectation hasn't been broken
by systemd this time.

There are Linux distros for big IBM iron: anyone cares to have
a look how the default policy settings are there? (As that's
SuSE's realm, mainly, I'd guess they are similar enough to
RedHat that they're using something along these lines).

Cheers

[1] Don't take me wrong. Those desktop thingies have their place.
   Just not on "my" desktop, dammit :-)
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlopFhsACgkQBcgs9XrR2kaUcwCeMgdvqAWryzSSxE5W3r8+Ol2o
NE8AnAlA3wWeb2dJ4xdTN5Cyy+3Al/PT
=xit+
-END PGP SIGNATURE-

Re: Embarrassing security bug in systemd

[Tixy]

On Thu, 2017-12-07 at 03:03 -0600, Dave Sherohman wrote:
> 
> I no longer have any non-systemd machines handy to verify this on, but
> my memory is that I have *always* been able to use halt/poweroff/reboot
> commands from the console without requiring sudo or entering a password,
> and I've been using Debian since 2000ish, well before systemd was even a
> gleam in some programmer's eye.

I'm running Jessie (with systemd running but booting with sysvinit) and
trying to execute halt/poweroff/reboot/shutdown from a terminal without
root privileges gives an error saying I must be superuser. Which has
always been my experience in 10 years of using Debian.

>From a desktop environment it's usually been possible to shut a machine
down from a menu option, though at least on one release I ended up
having to hack some policy config to allow that to work.

-- 
Tixy

Re: Embarrassing security bug in systemd

[Dave Sherohman]

On Thu, Dec 07, 2017 at 11:26:45AM +1300, Ben Caradoc-Davies wrote:
> Special privileges have been granted to console users for as long as I can
> remember, long before systemd, because they have physical access to the
> machine. Console users typically are also permitted to mount, unmount, and
> eject removable media, and have access to audio devices.

I think this is a key point that's been overlooked in the complaints
about this behavior:  It has nothing to do with systemd.

I no longer have any non-systemd machines handy to verify this on, but
my memory is that I have *always* been able to use halt/poweroff/reboot
commands from the console without requiring sudo or entering a password,
and I've been using Debian since 2000ish, well before systemd was even a
gleam in some programmer's eye.  /sbin/shutdown may have also been
freely available at the console, but I don't remember that one clearly,
since I didn't use it all that often once I discovered the others.

But, then, even if I'm remembering incorrectly, it's still a policy
matter, not a technical one.  If the policy was changed at the same time
as Debian switched to systemd, that's just a coincidence of timing and
the same policy change could have happened while still under sysvinit.

-- 
Dave Sherohman

Re: Embarrassing security bug in systemd

[Joe]

On Wed, 6 Dec 2017 17:35:18 -0500
Michael Stone  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

Re: Embarrassing security bug in systemd

[David Baron]

On יום רביעי, 6 בדצמבר 2017 22:52:17 IST 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
> 
> $ 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?
> 
> Searching the man pages I couldn't find a way to fix this.  How can
> that be stopped?
> 
> [1] Of course, this is not docuemented in systemctl(1) as usual with
> systemd.  Also, according to the man page, systemctl must be
> called with a "COMMAND" argument which /sbin/reboot doesn't do.
> Obviously, systemctl looks at the name it was called and somehow
> uses that as command.  The admin shall guess about this.
> 
> 
> urs

I find I need to use "sudo" to shutdown or reboot. That is using those 
(pseudo?) commands. Maybe their scripts check before going to sysemctl

Re: Embarrassing security bug in systemd

[Eric S Fraga]

On Wednesday,  6 Dec 2017 at 22:52, 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.

Security issues etc. aside, I love the fact that your 10 year old is
asking such a question!
-- 
Eric S Fraga via Emacs 27.0.50, org 9.1.4


signature.asc
Description: PGP signature