Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 378451 - >=sys-apps/{portage-2.1.10.5,2.2.0_alpha44} and >=app-admin/logrotate-3.8.0 fail to rotate summary.log
Summary: >=sys-apps/{portage-2.1.10.5,2.2.0_alpha44} and >=app-admin/logrotate-3.8.0 f...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks: 373933
  Show dependency tree
 
Reported: 2011-08-09 09:16 UTC by Malte Starostik
Modified: 2011-08-27 18:06 UTC (History)
6 users (show)

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


Attachments
run logrotate as root:portage (portage-logrotate-perms.diff,355 bytes, patch)
2011-08-09 09:18 UTC, Malte Starostik
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Malte Starostik 2011-08-09 09:16:41 UTC
Since the fix for Bug #374287, as logrotate now runs as portage:portage, it cannot compress the rotated /var/log/portage/elog/summary.log anymore as permissions get in the way.
As a consequence, this log will no longer be rotated.

Reproducible: Always

Steps to Reproduce:
1. touch /var/log/portage/elog/summary.log-19700101
2. chmod g+w /var/log/portage/elog/summary.log-19700101
3. logrotate -f /etc/logrotate.conf

Actual Results:  
error: error setting owner of /var/log/portage/elog/summary.log-19700101.gz: Operation not permitted

ls -l /var/log/portage/elog
-rw------- 1 portage root   0 Aug  9 11:05 logrotate_temp.jrMzUc
-rw-rw-r-- 1 root    root   0 Aug  9 11:04 summary.log-19700101


Expected Results:  
/var/log/portage/elog/summary.log-19700101 should have been compressed to /var/log/portage/elog/summary.log-19700101.gz

This is reproducible on any system I tried running those versions, here's an example:

Portage 2.2.0_alpha50 (default/linux/amd64/10.0, gcc-4.4.5, glibc-2.12.2-r0, 2.6.39-gentoo-r3-jmb x86_64)
=================================================================
System uname: Linux-2.6.39-gentoo-r3-jmb-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E8300_@_2.83GHz-with-gentoo-2.0.3
Timestamp of tree: Tue, 09 Aug 2011 06:00:01 +0000
app-shells/bash:          4.1_p9
dev-lang/python:          2.7.1-r1, 3.1.3-r1
dev-util/cmake:           2.8.4-r1
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.0.3
sys-apps/openrc:          0.8.3-r1
sys-apps/sandbox:         2.4
sys-devel/autoconf:       2.68
sys-devel/automake:       1.11.1
sys-devel/binutils:       2.20.1-r1
sys-devel/gcc:            4.4.5
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82
sys-kernel/linux-headers: 2.6.36.1 (virtual/os-headers)
sys-libs/glibc:           2.12.2
Repositories: gentoo jmb
Installed sets: @jmb-nagios
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=core2 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--jobs --load-average=3.0"
FEATURES="assume-digests binpkg-logs candy distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS=""
GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/"
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en"
MAKEOPTS="-j -l3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/mnt/portage/repo/gentoo"
PORTDIR_OVERLAY="/mnt/portage/repo/jmb"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl ads amd64 apache2 berkdb bzip2 cli cracklib crypt cxx dri fortran gdbm gpm iconv ipv6 jpeg kerberos ldap lzma mmx modules mudflap multilib ncurses nls nptl nptlonly openmp pam pam_krb5 pcre perl png pppd python readline sasl session smp snmp sse sse2 ssl sysfs tcpd threads udev unicode vim-syntax xattr xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="braindump flow karbon kexi kpresenter krita tables words" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" PHP_TARGETS="php5-3" QEMU_SOFTMMU_TARGETS="x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="dummy fbdev glint intel mach64 mga neomagic nouveau nv r128 radeon savage sis tdfx trident v4l vesa via vmware" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" 
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Malte Starostik 2011-08-09 09:18:24 UTC
Created attachment 282657 [details, diff]
run logrotate as root:portage

This still keeps logrotate from complaining about the directory permissions but also makes rotating actually work ;)
Comment 2 Zac Medico gentoo-dev 2011-08-09 10:48:49 UTC

*** This bug has been marked as a duplicate of bug 374287 ***
Comment 3 Malte Starostik 2011-08-09 12:15:57 UTC
Sorry, but this is a different issue that is only caused by the fix for bug 374287.
Comment 4 Daniel Gryniewicz (RETIRED) gentoo-dev 2011-08-10 12:08:28 UTC
Simple enough solution: make the elog directory group writable by portage.  I'm not sure the solution given in the patch is good, since it seems to work around the fix for the CVE.  Sure, it kills the warning, but it still allows modifying files as root, which I believe allows the symlink attack.
Comment 5 Malte Starostik 2011-08-10 12:52:16 UTC
(In reply to comment #4)
> Simple enough solution: make the elog directory group writable by portage.  I'm
> not sure the solution given in the patch is good, since it seems to work around
> the fix for the CVE.  Sure, it kills the warning, but it still allows modifying
> files as root, which I believe allows the symlink attack.

That won't cut it:

# logrotate -f /etc/logrotate.conf 
error: error setting owner of /var/log/portage/elog/summary.log-19700101.gz: Die Operation ist nicht erlaubt

# ls -ld $(pwd)
drwxrws--- 2 portage root 4096 10. Aug 14:43 /var/log/portage/elog
# chown portage:portage .
# logrotate -f /etc/logrotate.conf 
error: error setting owner of /var/log/portage/elog/summary.log-19700101.gz: Die Operation ist nicht erlaubt

Please note that this is not a warning but a fatal error and with each run of logrotate, an empty logrotate_temp.XXXXXX file is created to stay until manually cleaned up.  The problem seems to be that the directory is owned by portage:root, but the log file is not:

# ls -l
-rw-rw-r-- 1 root root 317 Aug  9 11:44 summary.log
Comment 6 Zac Medico gentoo-dev 2011-08-11 01:14:38 UTC
(In reply to comment #5)
> Please note that this is not a warning but a fatal error and with each run of
> logrotate, an empty logrotate_temp.XXXXXX file is created to stay until
> manually cleaned up.  The problem seems to be that the directory is owned by
> portage:root, but the log file is not:
> 
> # ls -l
> -rw-rw-r-- 1 root root 317 Aug  9 11:44 summary.log

This should fix it:

  chown root:portage /var/log/portage/elog/summary.log

Otherwise, portage will copy the group permission bits from the parent directory the next time that it writes to the file, as shown in the mod_save_summary changes in the following commit:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4d689ffbe80b8d5038cc0105ace69de7b80e6cb1
Comment 7 Jeremy Olexa (darkside) (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2011-08-11 04:00:44 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Please note that this is not a warning but a fatal error and with each run of
> > logrotate, an empty logrotate_temp.XXXXXX file is created to stay until
> > manually cleaned up.  The problem seems to be that the directory is owned by
> > portage:root, but the log file is not:
> > 
> > # ls -l
> > -rw-rw-r-- 1 root root 317 Aug  9 11:44 summary.log
> 
> This should fix it:
> 
>   chown root:portage /var/log/portage/elog/summary.log

Can the ebuild do that, please. I don't want to manually update XX machines.
Comment 8 Zac Medico gentoo-dev 2011-08-11 04:04:52 UTC
Like I mentioned at the end of comment #6, portage should do it automatically the next time that it writes to the file. It works by copying permissions from the /var/log/portage directory, which is fine as long as you have the default permissions set by portage.
Comment 9 Malte Starostik 2011-08-11 08:32:49 UTC
(In reply to comment #6)
> This should fix it:
> 
>   chown root:portage /var/log/portage/elog/summary.log

Nope.  portage:root or portage:portage would do it but I'm not sure whether that'd be okay for portage.

With "su portage portage" in /etc/logrotate.d/elog-save-summary, logrotate effectively runs as portage:portage.

It processes the file in two passes over subsequent executions.  In the first pass, it renames the existing summary.log to summary.log-$DATE.  This steps succeeds as user portage has write access to the parent dir.
By creating the phony summary.log-19700101, the steps to reproduce above simulate this has already happened.  One thing I forgot to mention in the report is that summary.log must exist as well.

The second pass then fails:
As a result of the second pass, summary.log-$DATE shall be compressed to summary.log-$DATE.gz.  For this,
* logrotate_temp.XXXXXX is created.  Due to logrotate's euid and the directory's sgid bit, this file is owned by portage:root.
* now, according to strace, logrotate tries to fchown() that open temp file to root:portage, presumably in order to match the ownership of summary.log-$DATE
* That fchown() fails and logrotate misleadingly barfs about setting the owner of summary.log-$DATE.gz when it actually still has the temporary name.

The group ownership doesn't really matter here, the fchwon() will fail unless summary.log is owned by *user* portage or logrotate runs as root.
Comment 10 Zac Medico gentoo-dev 2011-08-11 11:40:06 UTC
(In reply to comment #9)
> The second pass then fails:
> As a result of the second pass, summary.log-$DATE shall be compressed to
> summary.log-$DATE.gz.  For this,
> * logrotate_temp.XXXXXX is created.  Due to logrotate's euid and the
> directory's sgid bit, this file is owned by portage:root.

It came out portage:portage when I tried it, as expected from the "su portage portage" directive in the config file.

> * now, according to strace, logrotate tries to fchown() that open temp file to
> root:portage, presumably in order to match the ownership of summary.log-$DATE
> * That fchown() fails and logrotate misleadingly barfs about setting the owner
> of summary.log-$DATE.gz when it actually still has the temporary name.

It failed for me too. I think it's a bug in logrotate, since it shouldn't assume that it can chown to the owner of the file, since that would require superuser privileges.

> The group ownership doesn't really matter here, the fchwon() will fail unless
> summary.log is owned by *user* portage or logrotate runs as root.

Right, the fchown() call is just plain wrong. logrotate shouldn't assume that will work. Suppose the owner was some other random user in the portage group. The chown call would fail then too, without superuser privileges.

(In reply to comment #4)
> Simple enough solution: make the elog directory group writable by portage.  I'm
> not sure the solution given in the patch is good, since it seems to work around
> the fix for the CVE.  Sure, it kills the warning, but it still allows modifying
> files as root, which I believe allows the symlink attack.

Well, considering that the portage group is already sensitive to attack from various angles (see bug 149062), the symlink attack seems negligible. So, the "su root portage" solution would be fine with me. My only concern is that this will stop working in the future for "security" reasons.
Comment 11 Zac Medico gentoo-dev 2011-08-11 11:48:04 UTC
(In reply to comment #9)
> The second pass then fails:
> As a result of the second pass, summary.log-$DATE shall be compressed to
> summary.log-$DATE.gz. 

If anybody is trying to reproduce this, the simple way is to comment out "delaycompress" in /etc/logrotate.d/elog-save-summary before running `logrotate -f /etc/logrotate.conf`. That allows you to trigger the error in a single pass.
Comment 12 Zac Medico gentoo-dev 2011-08-12 03:20:16 UTC
I'm planning to make portage copy portage:portage ownership bits from /var/log/portage down to /var/log/portage/elog/summary.log. That way it should be compatible with the "su portage portage" directive.
Comment 13 Zac Medico gentoo-dev 2011-08-12 09:48:06 UTC
(In reply to comment #12)
> I'm planning to make portage copy portage:portage ownership bits from
> /var/log/portage down to /var/log/portage/elog/summary.log. That way it should
> be compatible with the "su portage portage" directive.

This is implemented in git:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e3954bead8d7e37978cac4ae5a5ec7836d3dcd1c
Comment 14 Zac Medico gentoo-dev 2011-08-27 17:54:48 UTC
(In reply to comment #7)
> Can the ebuild do that, please. I don't want to manually update XX machines.

We had a problem with the default permissions reported in bug 377177, so I've updated the ebuild to initialize /var/log/portage permissions in pkg_preinst:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/portage/portage-2.1.10.11.ebuild?view=log#rev1.4
Comment 15 Zac Medico gentoo-dev 2011-08-27 18:06:03 UTC
This is fixed in 2.1.10.11 and 2.2.0_alpha51.