The current screen 4.4.0 ebuild forces the socked dir to "/tmp/screen": --with-socket-dir="${EPREFIX}/tmp/screen" \ The default behavior of screen is to use $HOME/.screen/. This has the advantage that this works flawlessly with screen installed without suid. There seems to be no way to restore the default behavior when a hardcoded dir is set compile-time. I'd propose to just remove the --with-socket-dir parameter from the configure line and use the default upstream behavior. If there's a strong need for some for the hardcoded behavior we could also make this configurable via a use flag.
Can I raise attention to this issue? I'm maintaining a copy of the screen ebuild for my own use cases due to this issue, but that shouldn't be. I really don't see why we're hardcoding something to a non-default where upstream's default should work perfectly well.
Heavy ping on this issue. Hardcoded /tmp/screen raises issue with opentmpfiles: $ screen -r Directory '/tmp/screen' must have mode 777. Because opentmpfiles sets it to 0775 as it should be for SUID version of the screen, which we don't have now. $ cat /usr/lib/tmpfiles.d/screen.conf d /tmp/screen 0775 root utmp Probably switching screen to default ~/.screen *and* removing /usr/lib/tmpfiles.d/screen.conf will be the best course of action.
Why socket is needed in /tmp/screen in the first place? Is it there for multiuser mode? Maybe use --with-socket-dir only with USE="multiuser"?
Hmm, strange, portage somehow strips sgid bit from screen binary, that's why this problem occurs.
(In reply to Andrew Savchenko from comment #4) > Hmm, strange, portage somehow strips sgid bit from screen binary, that's why > this problem occurs. Well, that was a problem on my side, but quite a delicate one, so I'll document it here. I use lxc image to build packages, it has fsetid capability dropped by default. And in *some* cases this leads to *silent* chmod(S_ISGID) errors: it doesn't work, but returns success. This is unexpected behaviour for me, but it is documented (man 2 chmod): > If the calling process is not privileged (Linux: does not have the CAP_FSETID > capability), and the group of the file does not match the effective group ID > of the process or one of its supplementary group IDs, the S_ISGID bit will be > turned off, but this will not cause an error to be returned. Just a handful of packages were affected by this, including screen.
(In reply to Hanno Böck from comment #1) > Can I raise attention to this issue? > > I'm maintaining a copy of the screen ebuild for my own use cases due to this > issue, but that shouldn't be. I really don't see why we're hardcoding > something to a non-default where upstream's default should work perfectly > well. You're right. And why 'utmp' sgid screen binary, for utmp record? for a just logged in user? :(
With the 'new' tmpfiles_process screen.conf in pkg_postinst() you would alter that conf-file with a /etc/portage/bashrc hook for example, couldn't you?
