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?
I just spent way too much time investigating how to move screen away from the global /tmp and realized that much of the confusion in the ebuild & this bug comes from unnecessarily conflating the +/- multiuser use cases. It seems that the whole tmpfiles.d thing was necessary when the socketdir was set to /run (because ordinary users cannot create directories in /run), so it needed to be pre-created via tmpfiles.d. Fine..but that essentially got made redundant again by the later move to /tmp where everybody *can* create whatever they want. This smells and did not help with permissions, but whatever. Andy's comment #2 (do not set explicit socket dir + do not use tmpfiles.d) is right on the money and IMHO the best way forward for -multiuser. Maybe we can even use this as opportunity to remove the SUID stuff for this case, which seems to be the most common and default. For +multiuser we can either: - keep using /tmp as coordination directory, remove the tmpfiles.d config - revert to /run, keep the tmpfiles.d config since it's necessary Does this make sense? Looks like we are not far off from a better solution, just make things conditional on multiuser.
(In reply to Holger Hoffstätte from comment #8) > Does this make sense? Looks like we are not far off from a better solution, > just make things conditional on multiuser. Ninja hack version doing just that at: https://github.com/hhoffstaette/portage/blob/master/app-misc/screen/screen-4.9.1-r1.ebuild -multiuser is still suid (for terminal reasons, not sure if required), uses ~/.screen and no longer installs/requires tempfiles.d +multiuser uses tmpfiles.d config pointing to /run No more /tmp, no more confusion
