Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 141619 - [PATCH] portage keeps directory permissions but updates file permissions on merge
Summary: [PATCH] portage keeps directory permissions but updates file permissions on m...
Status: RESOLVED DUPLICATE of bug 396153
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 140250 172576 174916 182983 193728 199197 395961 421533 601508 (view as bug list)
Depends on:
Blocks: 193766 238335
  Show dependency tree
 
Reported: 2006-07-24 12:50 UTC by Jakub Moc (RETIRED)
Modified: 2018-10-09 17:03 UTC (History)
13 users (show)

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


Attachments
implement FEATURES=merge-dir-perms and enable in make.globals (merge_dir_perms.patch,2.17 KB, patch)
2008-01-11 02:38 UTC, Zac Medico
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Moc (RETIRED) gentoo-dev 2006-07-24 12:50:07 UTC
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.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-07-24 12:50:52 UTC
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
Comment 2 Marius Mauch (RETIRED) gentoo-dev 2006-07-24 13:51:38 UTC
<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
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-07-24 14:06:37 UTC
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...)
Comment 4 Marius Mauch (RETIRED) gentoo-dev 2006-07-24 14:22:23 UTC
(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.
Comment 5 SpanKY gentoo-dev 2006-07-30 21:27:14 UTC
i see this as being a dupe of this thread:
http://article.gmane.org/gmane.linux.gentoo.portage.devel/2182
Comment 6 Vlastimil Babka (Caster) (RETIRED) gentoo-dev 2006-10-16 01:53:31 UTC
(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.
Comment 7 Marius Mauch (RETIRED) gentoo-dev 2007-01-11 10:15:48 UTC
Did we ever get to a conclusion here?
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2007-02-11 23:04:51 UTC
(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.

Comment 9 Marius Mauch (RETIRED) gentoo-dev 2007-04-03 21:32:31 UTC
*** Bug 172576 has been marked as a duplicate of this bug. ***
Comment 10 Marius Mauch (RETIRED) gentoo-dev 2007-04-17 17:37:17 UTC
*** Bug 174916 has been marked as a duplicate of this bug. ***
Comment 11 Martin von Gagern 2007-04-17 19:39:35 UTC
(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.
Comment 12 Martin von Gagern 2007-06-05 14:23:41 UTC
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.
Comment 13 Jakub Moc (RETIRED) gentoo-dev 2007-06-15 09:43:51 UTC
*** Bug 140250 has been marked as a duplicate of this bug. ***
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2007-06-23 17:00:42 UTC
*** Bug 182983 has been marked as a duplicate of this bug. ***
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2007-09-25 10:34:45 UTC
*** Bug 193728 has been marked as a duplicate of this bug. ***
Comment 16 Jakub Moc (RETIRED) gentoo-dev 2007-12-05 11:00:56 UTC
*** Bug 199197 has been marked as a duplicate of this bug. ***
Comment 17 Jakub Moc (RETIRED) gentoo-dev 2008-01-03 22:38:55 UTC
(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.
Comment 18 Marius Mauch (RETIRED) gentoo-dev 2008-01-11 01:33:50 UTC
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)
Comment 19 Zac Medico gentoo-dev 2008-01-11 02:38:05 UTC
Created attachment 140656 [details, diff]
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.
Comment 20 Marius Mauch (RETIRED) gentoo-dev 2008-01-11 03:22:12 UTC
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?)
Comment 21 Zac Medico gentoo-dev 2008-01-11 03:37:35 UTC
(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?
Comment 22 Marius Mauch (RETIRED) gentoo-dev 2008-01-11 04:01:37 UTC
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.
Comment 23 Peter Volkov (RETIRED) gentoo-dev 2008-01-11 10:17:48 UTC
(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.
Comment 24 Marius Mauch (RETIRED) gentoo-dev 2008-01-12 03:43:00 UTC
(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.
Comment 25 Zac Medico gentoo-dev 2011-03-11 00:53:40 UTC
(In reply to comment #24)
> 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.

To use Debian as an example, they have a dpkg-statoverride command that's used to configure (or query) these kinds of permission overrides.
Comment 26 Zac Medico gentoo-dev 2011-12-26 22:51:58 UTC
*** Bug 395961 has been marked as a duplicate of this bug. ***
Comment 27 Zac Medico gentoo-dev 2011-12-27 01:24:45 UTC

*** This bug has been marked as a duplicate of bug 396153 ***
Comment 28 Zac Medico gentoo-dev 2012-06-17 15:26:46 UTC
*** Bug 421533 has been marked as a duplicate of this bug. ***
Comment 29 Zac Medico gentoo-dev 2016-12-03 20:31:03 UTC
*** Bug 601508 has been marked as a duplicate of this bug. ***
Comment 30 Zac Medico gentoo-dev 2018-10-09 17:01:50 UTC
Bug 396153 proposes a PMS extension that will allow users to persistently override directory permissions when necessary.

Also, I'm planning a FEATURES=overwrite-dir-perms setting, see bug 654138.
Comment 31 Zac Medico gentoo-dev 2018-10-09 17:03:07 UTC
*** Bug 668158 has been marked as a duplicate of this bug. ***