Feature #12162

Give the internal XMPP service admins the credentials they need

Added by intrigeri 2017-01-21 17:45:10 . Updated 2017-04-01 07:22:07 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Tails_2.12
Start date:
2017-01-21
Due date:
% Done:

100%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

At least:

  • SSH access
  • prosodyctl
  • service prosody restart
  • read-write access to /etc/prosody/*
  • … and whatever they’ll discover they need.

Subtasks

Related issues

Blocks Tails - Feature #12161: Monitor that our internal XMPP server is up Rejected 2017-01-21

History

#1 Updated by intrigeri 2017-01-21 17:53:17

  • Description updated

#2 Updated by intrigeri 2017-01-21 17:55:09

  • Description updated

#3 Updated by Dr_Whax 2017-01-22 21:34:10

Could you add the following directory to be backupped as well?

/var/lib/prosody/*

#4 Updated by intrigeri 2017-01-27 08:48:58

  • Assignee changed from intrigeri to Dr_Whax

Please reassign to me once a team has been assembled and I have the list of service admins + their SSH pub key. Thanks in advance! (The Ideal™ Redmine semantics would be that I create a new ticket about that, and mark this one as blocked by that other, new ticket, but let’s save some paperwork :)

#5 Updated by Dr_Whax 2017-01-29 12:01:07

  • Assignee changed from Dr_Whax to intrigeri

Hi,

The team consists of:

- emmapeel

- spriver
- DrWhax

From what I understand from them, you might already have ssh pubkeys from all of them. If there is anything missing, please reassign to me and i’ll arrange.

#6 Updated by intrigeri 2017-02-11 13:36:05

  • Description updated
  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

#7 Updated by intrigeri 2017-02-11 14:26:06

Dr_Whax wrote:
> Could you add the following directory to be backupped as well?

Done. I now have:

  include:
    - /etc
    - /var/backups
    - /var/lib/prosody
    - /var/lib/puppet
    - /var/lib/tor/ssh-hidden
    - /var/lib/tor/xmpp-hidden

#8 Updated by intrigeri 2017-02-11 14:27:38

Dr_Whax wrote:
> From what I understand from them, you might already have ssh pubkeys from all of them. If there is anything missing, please reassign to me and i’ll arrange.

Done.

#9 Updated by intrigeri 2017-02-11 15:12:36

  • Assignee changed from intrigeri to Dr_Whax

DrWhax says he’ll provide the sudo config.

#10 Updated by Dr_Whax 2017-02-12 22:14:49

  • Assignee changed from Dr_Whax to intrigeri

Please review+merge+deploy: drwhax/puppet-tails branch: prosody_update

PS: I’m saving paperwork, if I should not do this, please let me know.

#11 Updated by intrigeri 2017-02-13 08:17:21

> Please review+merge+deploy: drwhax/puppet-tails branch: prosody_update

Three comments:

  • This branch makes the prosody config world-readable, which is not the case by default on Debian, presumably for good reasons. Let’s avoid doing that if possible.
  • I really prefer when a service isn’t allowed to modify its own configuration, so it would be nicer if those files were rw for the prosody_admin group, only readable by the prosody user and group, and not readable by anyone else. But I don’t know how to do that with regular Unix permissions so I see two options:
    • either create a prosody_admin user and make these files owned by prosody_admin:prosody and 2750
    • or use ACLs (examples in tails::rsync), but this won’t work as:
  • Changing permissions this way will be overridden on next package upgrade. The right way to change ownership/perms for files shipped by Debian packages is dpkg-statoverride. Sadly our puppet-apt module doesn’t support that yet, but e.g. https://github.com/example42/puppet-apt/blob/master/manifests/dpkg_statoverride.pp does. So I will add support for dpkg-statoverride in our puppet-apt module, and then we can use that.

So the best plan I could come up with so far is:

  1. create a prosody_admin user
  2. add support for dpkg-statoverride in our puppet-apt
  3. make these files owned by prosody_admin:prosody and 2750 using apt::dpkg_statoverride

This feels a bit complicated though, so maybe there’s a better plan :)

Another option would be to allow you folks to run sudoedit /etc/prosody/* or similar (to be translated into sudo syntax). But likely this won’t play nicely with your plan to use Ansible to deploy these files.

Thoughts, better options?

#12 Updated by intrigeri 2017-02-14 16:56:23

  • Assignee changed from intrigeri to Dr_Whax
  • % Done changed from 10 to 20

Implemented this plan, let me know if you need more access.

#13 Updated by intrigeri 2017-03-08 15:16:55

  • blocks Feature #12161: Monitor that our internal XMPP server is up added

#14 Updated by anonym 2017-03-09 14:00:32

  • Target version changed from Tails_2.11 to Tails_2.12

#15 Updated by Dr_Whax 2017-03-18 21:20:22

intrigeri wrote:
> > Please review+merge+deploy: drwhax/puppet-tails branch: prosody_update
>
> Three comments:
>
> * This branch makes the prosody config world-readable, which is not the case by default on Debian, presumably for good reasons. Let’s avoid doing that if possible.
> * I really prefer when a service isn’t allowed to modify its own configuration, so it would be nicer if those files were rw for the prosody_admin group, only readable by the prosody user and group, and not readable by anyone else. But I don’t know how to do that with regular Unix permissions so I see two options:
> either create a prosody_admin user and make these files owned by prosody_admin:prosody and 2750
> or use ACLs (examples in tails::rsync), but this won’t work as:
> * Changing permissions this way will be overridden on next package upgrade. The right way to change ownership/perms for files shipped by Debian packages is dpkg-statoverride. Sadly our puppet-apt module doesn’t support that yet, but e.g. https://github.com/example42/puppet-apt/blob/master/manifests/dpkg_statoverride.pp does. So I will add support for dpkg-statoverride in our puppet-apt module, and then we can use that.
>
> So the best plan I could come up with so far is:
>
> # create a prosody_admin user
> # add support for dpkg-statoverride in our puppet-apt
> # make these files owned by prosody_admin:prosody and 2750 using apt::dpkg_statoverride
>
> This feels a bit complicated though, so maybe there’s a better plan :)
>
> Another option would be to allow you folks to run sudoedit /etc/prosody/* or similar (to be translated into sudo syntax). But likely this won’t play nicely with your plan to use Ansible to deploy these files.
>

Thanks for the review! sudoedit should be good! Even if we don’t use Ansible.. this is still up in the air..

#16 Updated by Dr_Whax 2017-03-18 21:20:32

  • Assignee changed from Dr_Whax to intrigeri

#17 Updated by intrigeri 2017-03-20 13:06:53

  • Assignee changed from intrigeri to Dr_Whax

>> So the best plan I could come up with so far is:
>>
>> # create a prosody_admin user
>> # add support for dpkg-statoverride in our puppet-apt
>> # make these files owned by prosody_admin:prosody and 2750 using apt::dpkg_statoverride

This (^) is the plan I’ve implemented.

>> Another option would be to allow you folks to run sudoedit /etc/prosody/* […]

This I didn’t do. So:

> Thanks for the review! sudoedit should be good! Even if we don’t use Ansible.. this is still up in the air..

Is what I did good enough, or not?

#18 Updated by Dr_Whax 2017-03-31 15:02:41

  • Assignee changed from Dr_Whax to intrigeri

intrigeri wrote:
> >> So the best plan I could come up with so far is:
> >>
> >> # create a prosody_admin user
> >> # add support for dpkg-statoverride in our puppet-apt
> >> # make these files owned by prosody_admin:prosody and 2750 using apt::dpkg_statoverride
>
> This (^) is the plan I’ve implemented.
>
> >> Another option would be to allow you folks to run sudoedit /etc/prosody/* […]
>
> This I didn’t do. So:
>
> > Thanks for the review! sudoedit should be good! Even if we don’t use Ansible.. this is still up in the air..
>
> Is what I did good enough, or not?

This worked just fine, thanks!

The only remaining stumbleblock for now seems to be 2 packages. Please see: 1da7754be513b90a3937a0051fd24dc53a13cd5f drwhax/minor_prosody_fixes

#19 Updated by intrigeri 2017-04-01 07:21:16

  • Status changed from In Progress to Resolved
  • QA Check set to Pass

> The only remaining stumbleblock for now seems to be 2 packages. Please see: 1da7754be513b90a3937a0051fd24dc53a13cd5f drwhax/minor_prosody_fixes

Merged and applied, thanks!

See also the cleanup commit 7df3920 I’ve added on top :)

#20 Updated by intrigeri 2017-04-01 07:21:57

  • Assignee deleted (intrigeri)

#21 Updated by intrigeri 2017-04-01 07:22:07

  • % Done changed from 20 to 100