Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 141936 - portage ownership silently renamed
Summary: portage ownership silently renamed
Status: RESOLVED INVALID
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-27 14:39 UTC by Geoffrey Clements
Modified: 2006-07-31 14:39 UTC (History)
0 users

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


Attachments
strace log (strace.log,46.85 KB, text/plain)
2006-07-31 13:04 UTC, Geoffrey Clements
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Geoffrey Clements 2006-07-27 14:39:00 UTC
Whilst writing an ebuild I've found that the fowners command has no effect, i.e. the referenced file remains at root:root.

emerge --info
Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686)
=================================================================
System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(TM) XP 2500+
Gentoo Base System version 1.6.15
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo"
CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://mirror.switch.ch/ftp/mirror/gentoo/ http://gentoo.modulix.net/gentoo/ http://gentoo.mirror.solnet.ch"
LINGUAS="en en_GB"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise /usr/portage/local/layman/sunrise"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow X acpi alsa apm arts audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdinstall cdparanoia cdr cli crypt dbus dlloader doc dri dvd dvdr dvdread eds emboss encode exif expat fam ffmpeg flac fortran gd gdbm gif glut gmp gpm gstreamer gtk gtk2 hal idn imagemagick imlib isdnlog java jpeg kde kdeenablefinal lcms lesstif libg++ mad mikmod mmx mng motif mp3 mpeg ncurses nls nptl nsplugin nvidia ogg opengl oss pam pcre pda pdflib perl png postgres pppd python qt qt3 qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl svga symlink tcltk tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis win32codecs wmf xine xml xmms xorg xv xvid zlib elibc_glibc input_devices_evdev input_devices_keyboard input_devices_mouse kernel_linux linguas_en linguas_en_GB userland_GNU video_cards_nvidia video_cards_nv video_cards_vesa video_cards_fbdev"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Marius Mauch (RETIRED) gentoo-dev 2006-07-27 14:44:34 UTC
Assuming you talk about a file that previously existed in ${ROOT}, in that case the behavior is expected, see my comments on bug #141619
Comment 2 Geoffrey Clements 2006-07-27 15:10:54 UTC
(In reply to comment #1)
> Assuming you talk about a file that previously existed in ${ROOT}, in that case
> the behavior is expected, see my comments on bug #141619
> 

Thanks for the fast answer.

I'm working on a new ebuild, these files didn't exist before (I was testing from a "clean" setup).  Also AIUI fowners changes the ownership under ${D} so I ran:
ebuild <an_ebuild> install

and checked in:
/var/tmp/portage/<ebuild>/image/<package>/path/to/file

and the file remained at root:root.

So it /appears/ that fowners does nothing.
Comment 3 Marius Mauch (RETIRED) gentoo-dev 2006-07-27 15:40:27 UTC
Ok, if the file isn't changed in $D this is valid.
However given that fowner is just

#!/bin/bash
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id: fowners 3483 2006-06-10 21:40:40Z genone $

slash=/
exec chown "${@/#${slash}/${D}${slash}}"

I'm not exactly sure how it can go wrong.
Does it work if instead of fowners you call chown in your ebuild?
Comment 4 Geoffrey Clements 2006-07-28 12:31:07 UTC
(In reply to comment #3)
> Ok, if the file isn't changed in $D this is valid.
> However given that fowner is just
> 
> #!/bin/bash
> # Copyright 1999-2006 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Id: fowners 3483 2006-06-10 21:40:40Z genone $
> 
> slash=/
> exec chown "${@/#${slash}/${D}${slash}}"
> 
> I'm not exactly sure how it can go wrong.
> Does it work if instead of fowners you call chown in your ebuild?
> 

Well there's not much to go wrong there :)

Ok - this is really weird, chown does _not_ work when run from the ebuild.  However, if I do the chown from the command line immediately after running "ebuild <file.ebuild> install" then that works.  I'm running as root here in both cases.

Just to make sure that both cases were using exactly the same command I got the ebuild to echo the full chown command to stdout then I used cut and paste to run the command from the command line manually.

Maybe privileges are dropped in the ebuild but that's just a guess which is probably not right because I see no error message.
Comment 5 Marius Mauch (RETIRED) gentoo-dev 2006-07-28 22:25:11 UTC
In what phase do you try to change the permissions? It should be in src_install, other phases may run with reduced priviledges.
Comment 6 Geoffrey Clements 2006-07-28 23:39:04 UTC
(In reply to comment #5)
> In what phase do you try to change the permissions? It should be in
> src_install, other phases may run with reduced priviledges.
> 

Here's the code:

src_install() {
	PORTCFG=$(python -c 'import portage; print portage.USER_CONFIG_PATH,') || die "Cannot get config path"
	exeinto /usr/sbin
	doexe postsync

	insinto ${PORTCFG}/bin
	doins bin/post_sync
	dosed "s:/etc/portage:${PORTCFG}:g" ${PORTCFG}/bin/post_sync

	insinto /usr/lib/postsync.d
	doins postsync.d/*

	fowners root:portage /usr/sbin/postsync ${PORTCFG}/bin/post_sync /usr/lib/postsync.d/*

	dodoc README ChangeLog doc/*
}
Comment 7 SpanKY gentoo-dev 2006-07-30 21:21:46 UTC
globing wont work as it is evaluated too early
Comment 8 Geoffrey Clements 2006-07-31 07:36:10 UTC
(In reply to comment #7)
> globing wont work as it is evaluated too early

Dah! - a basic error, thanks for pointing that one out (I must stop hacking after midnight).

During testing only
fowners root:portage /usr/sbin/postsync
was used (in an attempt to keep things simple) so I still have the reported problem.
Comment 9 SpanKY gentoo-dev 2006-07-31 10:53:07 UTC
so try doing like:
bash -x fowners root:portage /usr/sbin/postsync

and if that isnt useful, then try:
strace -o log fowners root:portage /usr/sbin/postsync
Comment 10 Geoffrey Clements 2006-07-31 13:04:06 UTC
Created attachment 93140 [details]
strace log
Comment 11 Geoffrey Clements 2006-07-31 13:05:05 UTC
(In reply to comment #9)
> so try doing like:
> bash -x fowners root:portage /usr/sbin/postsync
> 

See attachment

# ll /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync
-rwxr-xr-x 1 root root 3377 Jul 31 20:27 /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync

I'm no expert (it's the first time I've used strace) but this looks ok to me and yet the file ownership remains unchanged.
Comment 12 Geoffrey Clements 2006-07-31 13:07:57 UTC
Bugger - I screwed up the last post and missed off the bash -x output, here it is:

# ebuild postsync-0.1_alpha.ebuild install
>>> checking ebuild checksums ;-)
>>> checking auxfile checksums ;-)
>>> checking miscfile checksums ;-)
>>> checking postsync-0.1_alpha.tar.bz2 ;-)
>>> Unpacking source...
>>> Unpacking postsync-0.1_alpha.tar.bz2 to /var/tmp/portage/postsync-0.1_alpha/work
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/postsync-0.1_alpha/work/postsync ...
>>> Source compiled.
>>> Test phase [not enabled]: app-portage/postsync-0.1_alpha

>>> Install postsync-0.1_alpha into /var/tmp/portage/postsync-0.1_alpha/image/ category app-portage
+ slash=/
+ exec chown root:portage /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync
>>> Completed installing postsync-0.1_alpha into /var/tmp/portage/postsync-0.1_alpha/image/

man:

# ll /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync
-rwxr-xr-x 1 root root 3377 Jul 31 20:33 /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync
Comment 13 SpanKY gentoo-dev 2006-07-31 13:59:58 UTC
oh, this is a feature

portage silently resets all user/group from "portage" to "root"
Comment 14 Geoffrey Clements 2006-07-31 14:29:38 UTC
(In reply to comment #13)
> oh, this is a feature
> 
> portage silently resets all user/group from "portage" to "root"
> 

ahh - ok, thanks for your help.  Guess this bug can be closed then.
Comment 15 SpanKY gentoo-dev 2006-07-31 14:39:08 UTC
you'll have to do it in like pkg_postinst():
chgrp portage "${ROOT}"/usr/bin/postsync