141619 2006-07-24 12:50 0000 [PATCH] portage keeps directory permissions but updates file permissions on merge 2009-06-08 06:35:09 0000 1 1 1 Unclassified Gentoo Linux Eclasses and Profiles 2006.0 All Linux NEW P2 normal --- 193766 238335 1 1 jakub@gentoo.org dev-portage@gentoo.org csbugreg@netspace.net.au marduk@gentoo.org Martin.vGagern@gmx.net pva@gentoo.org staskorz@gmail.com throw_away_2002@yahoo.com toralf.foerster@gmx.de wschlich@gentoo.org jakub@gentoo.org 2006-07-24 12:50:07 0000 A sample ebuild stub to reproduce: <snip> # Copyright 1999-2006 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ inherit eutils DESCRIPTION="MIMEDefang is a mail filtering framework for sendmail" HOMEPAGE="http://www.mimedefang.org/" SRC_URI="" LICENSE="GPL-2" SLOT="0" KEYWORDS="~x86" DEPEND="" RDEPEND="${DEPEND}" pkg_setup() { enewgroup defang enewuser defang -1 -1 /var/spool/MIMEDefang defang } src_install() { keepdir /var/spool/{MIMEDefang,MD-Quarantine} chmod 0775 ${D}/var/spool/MIMEDefang chmod 0755 ${D}/var/spool/MD-Quarantine chown defang:defang ${D}/var/spool/{MIMEDefang,MD-Quarantine} } </snip> 1/ User doesn't exist + first emerge # ls -ld /var/spool/{MIMEDefang,MD-Quarantine} drwxr-xr-x 2 defang defang 96 2006-07-24 21:32 /var/spool/MD-Quarantine drwxr-xr-x 2 defang root 96 2006-07-24 21:32 /var/spool/MIMEDefang 2/ User does exist + re-emerge # ls -ld /var/spool/{MIMEDefang,MD-Quarantine} drwxr-xr-x 2 defang defang 96 2006-07-24 21:33 /var/spool/MD-Quarantine drwxr-xr-x 2 defang root 96 2006-07-24 21:33 /var/spool/MIMEDefang Still broken. 3/ User does exist + unmerge and emerge # ls -ld /var/spool/{MIMEDefang,MD-Quarantine} drwxr-xr-x 2 defang defang 96 2006-07-24 21:34 /var/spool/MD-Quarantine drwxrwxr-x 2 defang defang 96 2006-07-24 21:34 /var/spool/MIMEDefang That's what it should be like for the first time! 4/ unmerge + userdel -f defang + emerge # ls -ld /var/spool/{MIMEDefang,MD-Quarantine} drwxr-xr-x 2 defang defang 96 2006-07-24 21:33 /var/spool/MD-Quarantine drwxr-xr-x 2 defang root 96 2006-07-24 21:33 /var/spool/MIMEDefang Busted again. jakub@gentoo.org 2006-07-24 12:50:52 0000 Portage 2.1.1_pre3-r4 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r3 i686) ================================================================= System uname: 2.6.17-gentoo-r3 i686 AMD Athlon(tm) XP 1600+ Gentoo Base System version 1.12.1 ccache version 2.4 [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: 0.4.2-r1 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 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-r2, 2.16.93, 2.17, 2.17.50.0.2, 2.17.50.0.3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -fforce-addr -ftree-vectorize" 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/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -fforce-addr -ftree-vectorize" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical" FEATURES="autoconfig ccache collision-protect confcache distlocks metadata-transfer parallel-fetch sandbox sfperms splitdebug strict userfetch userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.sh.cvut.cz/MIRRORS/gentoo/gentoo ftp://ftp.fi.muni.cz/pub/linux/gentoo/" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--sort-common" LINGUAS="cs en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--progress" 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 /mnt/nfs/overlays/vmware" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext 7zip X X509 a52 aac acl acpi alsa apm asf audiofile bash-completion berkdb bluetooth bzip2 caps cddb cdparanoia cdr chroot cli crypt cscope css cups curl curlwrappers dbx dga dlloader dri dts dv dvd dvdr dvdread encode ethereal exif expat fam fbcon ffmpeg fftw firefox flac flash flatfile foomaticdb gdbm gif glibc-omitfp glut gmp gpm gstreamer iconv icq idn imagemagick imap imlib inifile ipv6 irda jack javascript jbig joystick jpeg jpeg2k kdeenablefinal kdehiddenvisibility lcms libcaca libg++ libsamplerate libwww lirc lm_sensors logrotate mad maildir matroska mikmod mime mmap mmx mng mp3 mpeg musepack musicbrainz ncurses nls nodrm nptl nptlonly nsplugin nvidia offensive ogg openal opengl pam pcre pdf perl png ppds python qt3 quicktime readline real reflection samba sdl session sftplogging skey sndfile speex spell spl sse ssl svg symlink tcpd theora threads tiff truetype udev unicode urandom usb v4l v4l2 vcd vorbis win32codecs wmf x264 xine xinerama xinetd xml xml2 xmlrpc xorg xosd xpm xv xvid xvmc zlib elibc_glibc input_devices_joystick input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux linguas_cs linguas_en lirc_devices_cph06x userland_GNU video_cards_fbdev video_cards_nv video_cards_nvidia video_cards_v4l video_cards_vesa video_cards_vmware" Unset: CTARGET, INSTALL_MASK, LC_ALL genone@gentoo.org 2006-07-24 13:51:38 0000 <genone> jakub: what are the perms in ${D}? <genone> jakub: also when you say "first emerge", are you _sure_ the dirs didn't exist previously? <jakub> genone: it does... enewuser creates it <genone> ignore enewuser <jakub> well then yeah, I'm pretty damn sure it doesn't, I've re-checked about 10 times while pulling my hair here <genone> "it" == ? <jakub> well, the dir that should be 775 user:group and is 755 user:root instead <jakub> no way to do that unless the user and group already exist <jakub> ie., exist _before_ emerge <jakub> genone: in ${D} it's correct, but doesn't get merged w/ those perms <genone> ok, so if I'm understanding this right useradd (called by enewuser) creates the dir in ${ROOT} with wrong perms/ownership <jakub> genone: there's no way to specify such thing in enewuser <genone> and portage doesn't change ownership/perms of existing files in ${ROOT] at merge time <jakub> yup <genone> the second is by design <jakub> genone: uhm? <genone> uhm what? <jakub> also, s/files/dirs/ - there are no files involved here <genone> dirs are files <jakub> well, by design doesn't seem to be very good here, because you get broken ebuild * genone is too lazy to type {dirs,files,fifos,devs,...} <genone> jakub: you'd rather break peoples systems? <jakub> shrug, broken how exactly? it permissions set in ebuild break the system, they are not probably sane... <jakub> whatever, any solution here? <genone> postinst <genone> or get spanky to fix enewuser to not create the dir in ${ROOT} <jakub> chown it in postinst? <jakub> well, then I don't exactly see the difference from changing the design, can break the system equally <genone> well, take it up on -dev if you want that to get changed <jakub> heh, not sure if that's the best place :=) usually doesn't get very productive <jakub> so, how viable is to change the eclass? <genone> ask Spanky jakub@gentoo.org 2006-07-24 14:06:37 0000 Uhm, reopening this and sending vapier's way... Two solutions I see here: - let people specify the owner and permissions for homedir in enewuser call - create the homedir in ${D} instead of ${ROOT} (Or, obviously let portage change the perms on merge but that's not exactly what portage folks like...) genone@gentoo.org 2006-07-24 14:22:23 0000 (In reply to comment #3) > (Or, obviously let portage change the perms on merge but that's not exactly > what portage folks like...) Ehm, I'm not attached to the behavior in one way or the other, but if this should get changed it needs the support from the community, not just yours. vapier@gentoo.org 2006-07-30 21:27:14 0000 i see this as being a dupe of this thread: http://article.gmane.org/gmane.linux.gentoo.portage.devel/2182 caster@gentoo.org 2006-10-16 01:53:31 0000 (In reply to comment #5) > i see this as being a dupe of this thread: > http://article.gmane.org/gmane.linux.gentoo.portage.devel/2182 Or bug 58611. genone@gentoo.org 2007-01-11 10:15:48 0000 Did we ever get to a conclusion here? jakub@gentoo.org 2007-02-11 23:04:51 0000 (In reply to comment #7) > Did we ever get to a conclusion here? No. :( The worst thing is the inconsistent behaviour, it's confusing and produces pretty inexplicable bugs. genone@gentoo.org 2007-04-03 21:32:31 0000 *** Bug 172576 has been marked as a duplicate of this bug. *** genone@gentoo.org 2007-04-17 17:37:17 0000 *** Bug 174916 has been marked as a duplicate of this bug. *** Martin.vGagern@gmx.net 2007-04-17 19:39:35 0000 (In reply to comment #10) > *** Bug 174916 has been marked as a duplicate of this bug. *** OK, the above mentioned bug was in the first place about a specific ebuild, openmotif, and its possible need to fix the mistakes of a previous revision. I guess this might already be fixed by postinst, without breaking much. As this thing was duped here, I'll give you my thoughts on the general issue. From the admin perspective I'd like to differentiate between directories owned exclusively by some package, and directories created in image to represent shared structures. So if foo-0.ebuild decides to make directory /var/lib/foo group writable, there might be a good reason for this, while doing the same for /var/lib is probably a bad idea. I would not want permissions for existing directories merged unconditionally, because it could overwrite modifications the admin made on purpose. However, if an ebuild chooses to change some permissions from the way they were before, there should be a way to do so. Something like this: src_postinst { echmod 755 775 /var/lib/foo } to say that permissions on /var/lib/foo should be changed to 775 if they had been 755 (the old default) before. This is still not perfect, because when the admin chooses to revert these changes, his modifications get overwritten the next time this package is upgraded. But to solve that issue, we would need some information about the version the ebuild currently being emerged is going to replace. Say "change mode if upgrading from Version <1.0" or something similar. It might also be nice to carry some mode information from the install phase into the merge or postinst phase. Then the install phase could say "let the newly installed versions of /var/lib/foo [recursively] override those already there", and there would be no need to specify the modes in the ebuild itself. I guess this could best be solved by some postinst script that is part of the package, created during install by some eclass function, will be merged with the rest, then run automatically, and deleted afterwards. I have no idea how all this might cooperate with portage, and if this would work equally well for ownership. On the other hand, I would think this a feasible approach for files as well, not only dirs. Maybe there should be some FEATURE or other tool for ebuild writers that complains if a file in image does not agree with wat is currently installed, so that forgotten changes will be noticed. Martin.vGagern@gmx.net 2007-06-05 14:23:41 0000 Found two new instances today: /usr/include/gnome-xml from dev-libs/libxml and /usr/include/lqt from media-libs/libquicktime had no execute bit set. Deleting dirs and remerging ebuilds solved the issue. Don't know where this came from. Could we ewarn about differences between present permissions and the permissions from the ebuild? That would be one step towards solving the problem, and should be better than what's there right now. jakub@gentoo.org 2007-06-15 09:43:51 0000 *** Bug 140250 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-06-23 17:00:42 0000 *** Bug 182983 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-09-25 10:34:45 0000 *** Bug 193728 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-12-05 11:00:56 0000 *** Bug 199197 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2008-01-03 22:38:55 0000 (In reply to comment #11) > I would not want permissions for existing directories merged unconditionally, > because it could overwrite modifications the admin made on purpose. You already get these overwritten w/ tons of ebuilds b/c people keep working around this portage bug via doing chmod/chown in unsandboxed phases. We really should move somewhere with this as this feature serves no real purpose but adding hacks to ebuilds. genone@gentoo.org 2008-01-11 01:33:50 0000 I think the real solution here would be to store the permissions/ownership in the installed package database and only preserve them if modified after installation to satisfy both use cases. But I'd rather want to include that in a general vdb redesign rather than adding yet another file (as extending CONTENTS isn't an option) zmedico@gentoo.org 2008-01-11 02:38:05 0000 Created an attachment (id=140656) implement FEATURES=merge-dir-perms and enable in make.globals With this patch, the average user who doesn't want to control directory permissions themselves will have permissions merged from ${D}. Users who want to manage directory permissions themselves can add FEATURES="-merge-dir-perms" to /etc/make.conf. genone@gentoo.org 2008-01-11 03:22:12 0000 I strongly dislike that hack, as it doesn't really help anyone, devs still have to work around the issue in postinst for older versions and users without that setting, and it really shouldn't be a optional thing anyway (and do I have to repeat that I don't want to bloat FEATURES with cornercase stuff?) zmedico@gentoo.org 2008-01-11 03:37:35 0000 (In reply to comment #18) > I think the real solution here would be to store the permissions/ownership in > the installed package database and only preserve them if modified after > installation to satisfy both use cases. What about multiple packages that install the same directory with different permissions? Whose permissions win? genone@gentoo.org 2008-01-11 04:01:37 0000 The vdb redesign would likely contain a central database about file objects, so the last one would win. But that shouldn't happen, as two packages trying to install the same dir with conflicting permissions would be detected with a central db. pva@gentoo.org 2008-01-11 10:17:48 0000 (In reply to comment #21) > What about multiple packages that install the same directory with different > permissions? Whose permissions win? This is ordinary collision and should be reported and fixed by maintainers of said packages. From the user point of view I think portage should keep permissions developer assigned (actually overrided default permissions), and there is no need to completely disable permission control mechanism (like -merge-dir-perms do). But user should have some way to override permissions. I do not know what is the best way to go but at least two possible solutions exist: 1. Either some user defined permission db (may be file with "file perm" entries and recursion mark for directories) 2. Or add portage FEATURE which keeps modified by user permissions and show a warning that permissions were changed. Variant 2. may be does not work right now as we have many packages which set permissions in pkg_postinst and will warn even if user want such different permissions. And yes central db simplify things and is necessary in any case. genone@gentoo.org 2008-01-12 03:43:00 0000 (In reply to comment #23) > (In reply to comment #21) > > What about multiple packages that install the same directory with different > > permissions? Whose permissions win? > > This is ordinary collision and should be reported and fixed by maintainers of > said packages. Well, multiple packages installing the same dir isn't a collision, only the different permissions would be and that's something we can't really detect atm without reference data. > From the user point of view I think portage should keep permissions developer > assigned (actually overrided default permissions), and there is no need to > completely disable permission control mechanism (like -merge-dir-perms do). > But user should have some way to override permissions. I do not know what is > the best way to go but at least two possible solutions exist: > > 1. Either some user defined permission db (may be file with "file perm" > entries and recursion mark for directories) > 2. Or add portage FEATURE which keeps modified by user permissions and show a > warning that permissions were changed. > > Variant 2. may be does not work right now as we have many packages which set > permissions in pkg_postinst and will warn even if user want such different > permissions. And yes central db simplify things and is necessary in any case. As said, IMO the best way is to track which permissions were set when a directory was merged, and on upgrades only preserve the current permissions if they differ from the saved state (keeping track of permissions has other benefits as well). On top of that a config file to specify wanted permissions could also be implemented, but I don't think that's really needed if we respect manual modifications to ownership/permissions. 140656 2008-01-11 02:38 0000 implement FEATURES=merge-dir-perms and enable in make.globals merge_dir_perms.patch text/plain SW5kZXg6IHB5bS9wb3J0YWdlLnB5Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHB5bS9wb3J0YWdlLnB5CShyZXZp c2lvbiA5MTYxKQorKysgcHltL3BvcnRhZ2UucHkJKHdvcmtpbmcgY29weSkKQEAgLTkzMDcsNiAr OTMwNyw5IEBACiAJCQkJCQl3cml0ZW1zZ19zdGRvdXQoIi0tLSAlcy9cbiIgJSBteWRlc3QpCiAJ CQkJCQlpZiBic2RfY2hmbGFnczoKIAkJCQkJCQlic2RfY2hmbGFncy5sY2hmbGFncyhteWRlc3Qs IGRmbGFncykKKwkJCQkJCWlmICJtZXJnZS1kaXItcGVybXMiIGluIHNlbGYuc2V0dGluZ3MuZmVh dHVyZXM6CisJCQkJCQkJb3MuY2htb2QobXlkZXN0LCBzdGF0LlNfSU1PREUobXlzdGF0LnN0X21v ZGUpKQorCQkJCQkJCW9zLmNob3duKG15ZGVzdCwgbXlzdGF0LnN0X3VpZCwgbXlzdGF0LnN0X2dp ZCkKIAkJCQkJZWxzZToKIAkJCQkJCSMgYSBub24tZGlyZWN0b3J5IGFuZCBub24tc3ltbGluay10 by1kaXJlY3RvcnkuICBXb24ndCB3b3JrIGZvciB1cy4gIE1vdmUgb3V0IG9mIHRoZSB3YXkuCiAJ CQkJCQlpZiBtb3ZlZmlsZShteWRlc3QsbXlkZXN0KyIuYmFja3VwIiwgbXlzZXR0aW5ncz1zZWxm LnNldHRpbmdzKSBpcyBOb25lOgpJbmRleDogY25mL21ha2UuZ2xvYmFscwo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBjbmYvbWFrZS5nbG9iYWxzCShyZXZpc2lvbiA5MTMwKQorKysgY25mL21ha2UuZ2xvYmFscwko d29ya2luZyBjb3B5KQpAQCAtMzMsNyArMzMsNyBAQAogUkVTVU1FQ09NTUFORD0iL3Vzci9iaW4v d2dldCAtYyAtdCA1IC1UIDYwIC0tcGFzc2l2ZS1mdHAgLU8gXCR7RElTVERJUn0vXCR7RklMRX0g XCR7VVJJfSIKIAogIyBEZWZhdWx0IHVzZXIgb3B0aW9ucwotRkVBVFVSRVM9ImRpc3Rsb2NrcyBt ZXRhZGF0YS10cmFuc2ZlciBzYW5kYm94IHNmcGVybXMgc3RyaWN0IHVubWVyZ2Utb3JwaGFucyB1 c2VyZmV0Y2giCitGRUFUVVJFUz0iZGlzdGxvY2tzIG1lcmdlLWRpci1wZXJtcyBtZXRhZGF0YS10 cmFuc2ZlciBzYW5kYm94IHNmcGVybXMgc3RyaWN0IHVubWVyZ2Utb3JwaGFucyB1c2VyZmV0Y2gi CiAKICMgRGVmYXVsdCBjaHVua3NpemUgZm9yIGJpbmhvc3QgY29tbXMKIFBPUlRBR0VfQklOSE9T VF9DSFVOS1NJWkU9IjMwMDAiCkluZGV4OiBiaW4vbWlzYy1mdW5jdGlvbnMuc2gKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gYmluL21pc2MtZnVuY3Rpb25zLnNoCShyZXZpc2lvbiA5MTMwKQorKysgYmluL21pc2Mt ZnVuY3Rpb25zLnNoCSh3b3JraW5nIGNvcHkpCkBAIC00NiwxMiArNDYsMTMgQEAKIAlwcmVwYWxs CiAKIAkjIE5vdyB3ZSBsb29rIGZvciBhbGwgd29ybGQgd3JpdGFibGUgZmlsZXMuCi0JZm9yIGkg aW4gJChmaW5kICIke0R9LyIgLXR5cGUgZiAtcGVybSAtMik7IGRvCisJZmluZCAiJHtEfSIgJygn IC10eXBlIGYgLW8gLXR5cGUgZCAnKScgLXBlcm0gLTIgLXByaW50MCB8IFwKKwkJd2hpbGUgcmVh ZCAtZCAkJ1wwJyBpIDsgZG8KIAkJdmVjaG8gLW5lICdcYScKLQkJdmVjaG8gIlFBIFNlY3VyaXR5 IE5vdGljZToiCi0JCXZlY2hvICItICR7aTokeyNEfTokeyNpfX0gd2lsbCBiZSBhIHdvcmxkIHdy aXRhYmxlIGZpbGUuIgotCQl2ZWNobyAiLSBUaGlzIG1heSBvciBtYXkgbm90IGJlIGEgc2VjdXJp dHkgcHJvYmxlbSwgbW9zdCBvZiB0aGUgdGltZSBpdCBpcyBvbmUuIgotCQl2ZWNobyAiLSBQbGVh c2UgZG91YmxlIGNoZWNrIHRoYXQgJFBGIHJlYWxseSBuZWVkcyBhIHdvcmxkIHdyaXRlYWJsZSBi aXQgYW5kIGZpbGUgYnVncyBhY2NvcmRpbmdseS4iCisJCWVxYXdhcm4gIlFBIFNlY3VyaXR5IE5v dGljZToiCisJCWVxYXdhcm4gIi0gJHtpOiR7I0R9OiR7I2l9fSB3aWxsIGJlIGEgd29ybGQgd3Jp dGFibGUgZmlsZS4iCisJCWVxYXdhcm4gIi0gVGhpcyBtYXkgb3IgbWF5IG5vdCBiZSBhIHNlY3Vy aXR5IHByb2JsZW0sIG1vc3Qgb2YgdGhlIHRpbWUgaXQgaXMgb25lLiIKKwkJZXFhd2FybiAiLSBQ bGVhc2UgZG91YmxlIGNoZWNrIHRoYXQgJFBGIHJlYWxseSBuZWVkcyBhIHdvcmxkIHdyaXRlYWJs ZSBiaXQgYW5kIGZpbGUgYnVncyBhY2NvcmRpbmdseS4iCiAJCXNsZWVwIDEKIAlkb25lCiAK