=gui-libs/display-manager-init-1.0-r2 installs /usr/bin/startDM without executable bit: # emerge --search gui-libs/display-manager-init [ Results for search key : gui-libs/display-manager-init ] Searching... * gui-libs/display-manager-init Latest version available: 1.0-r2 Latest version installed: 1.0-r2 Size of files: 0 KiB Homepage: https://wiki.gentoo.org/wiki/Project:X11 Description: RC init files for starting display and login managers License: GPL-2 # ls /usr/bin/startDM -lah -rw-rw-r--+ 1 root root 786 фев 14 22:02 /usr/bin/startDM Without exec bit Xorg fails to start via OpenRC script: # /etc/init.d/display-manager restart [4/4] display-manager | * Stopping sddm ... [ ok ] display-manager | * Setting up sddm ... display-manager |/etc/init.d/display-manager: line 186: /usr/bin/startDM: Permission denied [ ok ]
Cannot confirm. file has executable bit on all my machines. Do you have some install umask present?
Nothing of this. Do you have exec bit on /usr/portage/gui-libs/display-manager-init/files/startDM ? doexe copies file permission as is if execopts undefined. Why there doexec instead dobin in ebuild?
Yes, it has exec bit -rwxr-xr-x 1 root root 433 Feb 14 14:15 /usr/bin/startDM* From https://devmanual.gentoo.org/function-reference/install-functions/ > doexe Install an executable into the location provided by exeinto, by default with mode 0755 or with the install options set by exeopts Sounds pretty standard to me.
So here my file from git clone: ls -lah итого 32K drwxrwxr-x+ 2 portage users 4,0K фев 14 22:11 . drwxrwxr-x+ 3 portage users 4,0K фев 14 22:19 .. -rw-rw-r--+ 1 portage users 608 фев 11 20:49 display-manager.confd -rw-rw-r--+ 1 portage users 6,1K фев 11 20:49 display-manager.initd-r1 -rw-rw-r--+ 1 portage users 224 фев 11 20:49 display-manager-setup.initd -rw-rw-r--+ 1 portage users 786 фев 11 20:49 startDM -rw-rw-r--+ 1 portage users 200 фев 11 20:49 xdm.initd And my version of doexec (as sys-apps/portage-3.0.13) does not installs with 0755 permissions.
Just tried to emerge it, and it's there for me as well: # ls -l /usr/bin/startDM -rwxr-xr-x 1 root root 786 Feb 14 15:13 /usr/bin/startDM That there's something on your setup that prevent this and even keeps group write seems rather strange. But that aside, I do see no reason to use exeinto /usr/bin+doexe over a 1-line dobin. dobin will install there by default and set it executable as well, or am I missing something?
dobin and doexe do behave differently: doexe: install ${EXEOPTIONS} "$mysrc" "${ED%/}/${_E_EXEDESTTREE_#/}" exeoptions is empty here I believe, unless using exeopts dobin: install -m0755 -o ${PORTAGE_INST_UID:-0} -g ${PORTAGE_INST_GID:-0} "${x}" "${ED%/}/${_E_DESTTREE_#/}/bin" However, "install" would still use 755 here, unless yours is modified, e.g. I can "install noexec.sh /tmp" and my noexec.sh is now executable
(In reply to Ionen Wolkens from comment #5) > Just tried to emerge it, and it's there for me as well: > # ls -l /usr/bin/startDM > -rwxr-xr-x 1 root root 786 Feb 14 15:13 /usr/bin/startDM > > That there's something on your setup that prevent this and even keeps group > write seems rather strange. > > But that aside, I do see no reason to use exeinto /usr/bin+doexe over a > 1-line dobin. dobin will install there by default and set it executable as > well, or am I missing something? We're going to see why we need doexe soon ;) That startDM script is going to start having revisions attached to it startDM-r1/2 (like the other files have already started getting).
Seems like no one beside OP can reproduce the issue. The in-git file does have 644 and it still install as it should. The doexe uses $EXEOPTIONS set to -m0755. Whatever is the issue, it's not display-manager-init > # ls /usr/bin/startDM -lah > -rw-rw-r--+ 1 root root 786 фев 14 22:02 /usr/bin/startDM Do you notice the + at the end of mode settings? It means you have Posix ACL set there, and Portage does not do it. Perhaps you were playing around with ACLs and set some ACLs that are supposed to be inherted on /usr/bin, that altered the 'mask' ACL. Play around with 'getfacl' to see whats going on Because of the ACL I consider this bug report as invalid and closing as such.
When I do ebuild display-manager-init-1.0-r2.ebuild install I get file without exec flag: ebuild display-manager-init-1.0-r2.ebuild install ls -lah /var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/usr/bin -rw-rw-r--+ 1 root root 786 фев 15 10:12 startDM But when I do same thing with bare install, exec flag is set: install -m0755 "/var/tmp/portage/gui-libs/display-manager-init-1.0-r2/files/startDM" "/var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/usr/bin" ls -lah /var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/usr/bin -rwxr-xr-x 1 root root 786 фев 15 10:16 startDM So please get fixed this bug. I don't care if there ACL, Gentoo Linux supports it, and doexe has undocumented side effects. I don't mind, if there will be dobin/newbin instead doexe.
Mate, whatever is wrong, is not with this ebuild. You have ACL set there. We do not set ACLs. Start with "getfacl /usr/bin/startDM" to debug your system.
Here your getfacl, recursively: getfacl /var/tmp/portage/gui-libs/display-manager-init-1.0-r2 getfacl: Removing leading '/' from absolute path names # file: var/tmp/portage/gui-libs/display-manager-init-1.0-r2 # owner: portage # group: portage user::rwx # <-- +x is set group::--- other::--- getfacl /var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image getfacl: Removing leading '/' from absolute path names # file: var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/ # owner: root # group: root user::rwx # <-- +x is set group::r-x # <-- +x is set other::r-x # <-- +x is set getfacl /var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/usr/ getfacl: Removing leading '/' from absolute path names # file: var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/usr/ # owner: root # group: root user::rwx # <-- +x is set group::r-x # <-- +x is set other::r-x # <-- +x is set getfacl /var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/usr/bin/ getfacl: Removing leading '/' from absolute path names # file: var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/usr/bin/ # owner: root # group: root user::rwx # <-- +x is set group::r-x # <-- +x is set other::r-x # <-- +x is set getfacl /var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/usr/bin/startDM getfacl: Removing leading '/' from absolute path names # file: var/tmp/portage/gui-libs/display-manager-init-1.0-r2/image/usr/bin/startDM # owner: root # group: root user::rw- # <-- where is +x ??? user:winterheart:rw- group::r-- mask::rw- other::r--
> user:winterheart:rw- So, you set inherit acl for user winterheart, which gets inherted, and you blame gui-libs/display-manager-init for lack of exec bit, which is not the case. Please stop re-opening the bug. This has nothing to do with gui-libs/display-manager-init, you configured your system in a way that sets those ACL, this is not Gentoo's bug.
Just change ebuild exeinto /usr/bin doexe "${FILESDIR}"/startDM to dobin "${FILESDIR}"/startDM already.
Your inability to maintain configuration you set yourself does not constitute workarounds on our end. You configuration allow unprivileged user to edit root owned files that are not writable otherwise by non-root.
Regardless of any practical difference in behavior, I do think that dobin or newbin is a better choice for installing files in /usr/bin.
(In reply to Aisha Tammy from comment #7) > We're going to see why we need doexe soon ;) > That startDM script is going to start having revisions attached to it > startDM-r1/2 (like the other files have already started getting). That's what newbin is for. doexe/newexe are intended for installing files outside of */bin.
