DE-IBH / apt-dater

terminal-based remote package update manager
GNU General Public License v2.0
100 stars 24 forks source link

APT-DATER(8) -- Refresh -- Possible file permission problems -- Missing call to SUDO(8) #133

Closed nuxwin closed 7 years ago

nuxwin commented 7 years ago

Good morning,

It seems that sudo is not called in some contexts when it is expected to be. If one file from the /etc/apt/apt.conf.d directory on a target host has permissions such as 0640 (umask 027 due to permissions policy hardening), apt-dater fails due to an access permissions error. The workaround to solve that issue is to call the apt-dater-host commands through sudo on the updater host and to add the apt-dater-host command in list of allowed commands in the /etc/sudoers.d/apt-dater-host file of target hosts.

To summarize, the workaround is as follows:

On updater host ($HOME/.config/apt-dater/apt-dater.conf

...
[Commands]
CmdRefresh=sudo apt-dater-host refresh
CmdUpgrade=sudo apt-dater-host upgrade
CmdInstall=sudo apt-dater-host install %s
...

this, even if we have already $GETROOT="sudo"; in the /etc/apt-dater-host.conf conffile of target hosts.

On target hosts (/etc/sudoers.d/apt-dater-host)

# apt-dater-host sudoers.d config file
# ------------------------------------
#
# Please consider a look at /etc/sudoers.d/README howto enable this file.
#

# Keep apt-dater's MAINTAINER environment variable
Defaults    env_keep += MAINTAINER

# Allow members of group adm to execute the apt-get command
%adm        ALL=NOPASSWD: /usr/bin/apt-dater-host,/usr/bin/apt-get,/usr/sbin/needrestart

It is easy to reproduce the problem on target hosts directly:

apt-dater@jessie:~$ LANG=C apt-dater-host refresh 1>/dev/null 
Opening configuration file /etc/apt/apt.conf.d/01norecommend - ifstream::ifstream (13: Permission denied)
E: Opening configuration file /etc/apt/apt.conf.d/01norecommend - ifstream::ifstream (13: Permission denied)
apt-dater@jessie:~$

but

apt-dater@jessie:~$ LANG=C sudo apt-dater-host refresh 1>/dev/null 
apt-dater@jessie:~$

The problem is in the do_status() routine. In the piped command, you should call $DPKGTOOL through sudo too when that is expected. For instance:

...
unless(open(HAPT, '-|', ($GETROOT ? "$GETROOT " : ''). "$DPKGTOOL $DPKGARGS dist-upgrade")) {
...
}
...

instead of

...
unless(open(HAPT, "$DPKGTOOL $DPKGARGS dist-upgrade |")) {
...
}
...

From my point of view, external commands that are generally sysadmin commands and which are called through the apt-dater-host Perl script should be executed through sudo (when $GETROOT equal to sudo), and of course, each of them should be added in the /etc/sudoers.d/apt-dater-host file. There are APT-GET(8), APTITUDE(8) but also dpkg-query(1) and maybe some others... Don't forget that UMASK(2) 022 is not the default policy on all systems.

Info about my environment:

root@jessie:~# LANG=C lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.9 (jessie)
Release:    8.9
Codename:   jessie
root@jessie:~# LANG=C apt-cache show apt-dater-host |grep ^Version
Version: 1.0.0-2+deb8u1

See also APT-DATER -- File permission problems

liske commented 7 years ago

Using apt-get w/o being root is absolutely valid (as it is installed in /usr/bin rather than /usr/sbin). You might consider to use an alias, some script in /usr/local/bin or bind your SSH key to a wrapper scriped on the target host to wrap the apt-dater-host command by sudo.