Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 604998 - Maintainership request: app-admin/amazon-ec2-init
Summary: Maintainership request: app-admin/amazon-ec2-init
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Proxy Maintainers
URL:
Whiteboard:
Keywords:
Depends on: 603346
Blocks:
  Show dependency tree
 
Reported: 2017-01-07 22:30 UTC by Philippe Chaintreuil
Modified: 2017-08-05 16:03 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Chaintreuil 2017-01-07 22:30:44 UTC
Per bug #603346 I'm offering my services as a proxy-maintainer of app-admin/amazon-ec2-init.  My pre-existing Maintainer bug is bug #586390.
Comment 1 Michael Orlitzky gentoo-dev 2017-01-14 05:18:14 UTC
Can you rewrite the existing init script? Basically every line of it is wrong, so rather than file 15 different bugs, I'll just go through it here.

  depend() {
    before hostname
    need net.eth0
  }

The NIC name eth0 shouldn't be hard-coded, and this doesn't need to be run before the hostname service, because it shouldn't be overwriting the hostname service's configuration file (mentioned later). If anything, it should be "after hostname", to override it. But it would be better if /etc/init.d/hostname was not run at all when you're going to set the hostname dynamically.

  local hostname=$(wget -t 2 -T 5 -q -O -
                   http://169.254.169.254/latest/meta-data/local-hostname)
  echo "hostname=${hostname}" >> /etc/conf.d/hostname
  
This needs error checking. You have no idea what that call to wget is going to return, if it succeeds at all. And this service has no business overwriting the configured hostname, if there is one. Instead you should set the hostname using the "hostname" tool, but you should probably document that the usual hostname service should be removed from the boot runlevel to avoid confusion and race conditions.

  mkdir -p /root/.ssh

The permissions on that are too loose. The "checkpath" helper should be used instead, and it should be accessible only to root.

  local keys=$(wget -t 2 -T 5 -q -O -
               http://169.254.169.254/latest/meta-data/public-keys/
               | cut -d = -f 1 | xargs echo)
  [ -n "${keys}" ] && \
    wget -t 2 -T 5 -q -O - $(for key in $keys; do
      echo "http://169.254.169.254/latest/meta-data/public-keys/$key openssh-key"; done) \
      >> /root/.ssh/authorized_keys \
      2>/dev/null

This needs error checking, both for wget failures and on the contents (keys) that are returned. But more importantly, this is a huge security vulnerability, since anyone on the same physical segment as you can set his IP to 169.254.169.254 and send data into your authorized_keys. I see no way to avoid that, but there should be something that prevents it from biting unaware users. Maybe a conf.d file with an I_KNOW_WHAT_I_AM_DOING variable (default: false) that explains that you're opening a huge hole. The entire init script can bail unless I_KNOW_WHAT_I_AM_DOING is true.

The append ">>" operator is also wrong. After 5,000 reboots, you're going to have 5,000 (probably identical) entries in your .authorized_keys.

  if [ -f /root/.ssh/authorized_keys ]; then
    chown root:root /root/.ssh/authorized_keys
    chmod 0600 /root/.ssh/authorized_keys
  fi

The ownership and permissions on pre-existing files should not be modified, and that file is new, permissions/ownership should be set with checkpath and not chown/chmod.

There's also no stop() function for this service. There needs to be one, and it has to,

  a) Unset the hostname, if the hostname was set by start().
     Or at least revert the hostname, if you decide to overwrite
     the one set by /etc/init.d/hostname.

  b) Remove any new authorized_keys added by start().
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-08-05 16:03:44 UTC
We no longer use these bugs. See:

https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide#Taking_over_an_existing_package

Long story short:

1. If your request has been fulfilled already and you're the maintainer, ignore this.

2. If you have submitted the ebuilds separately, we'll handle it there. If that's via a bug, please make sure that proxy-maint@ is in CC. Feel free to ping us if things aren't moving forward for a long time.

3. If you haven't submitted anything yet, please submit a meaningful change to the package (bugfix, version bump, ebuild update...) along with the maintainer update and you'll become the maintainer when we merge it.

Sorry for the trouble.