Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 591772 - app-misc/screen: hardcoded socked dir using screen without suid
Summary: app-misc/screen: hardcoded socked dir using screen without suid
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 2 votes (vote)
Assignee: Sven Wegener
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-21 07:47 UTC by Hanno Böck
Modified: 2024-02-21 15:50 UTC (History)
8 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hanno Böck gentoo-dev 2016-08-21 07:47:27 UTC
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.
Comment 1 Hanno Böck gentoo-dev 2020-03-02 10:12:16 UTC
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.
Comment 2 Andrew Savchenko gentoo-dev 2021-06-03 10:49:24 UTC
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.
Comment 3 Andrew Savchenko gentoo-dev 2021-06-03 11:05:46 UTC
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"?
Comment 4 Andrew Savchenko gentoo-dev 2021-06-03 11:18:42 UTC
Hmm, strange, portage somehow strips sgid bit from screen binary, that's why this problem occurs.
Comment 5 Andrew Savchenko gentoo-dev 2021-06-04 07:52:19 UTC
(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.
Comment 6 Enrique Domínguez 2021-10-13 01:28:41 UTC
(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? :(
Comment 7 Pascal Jäger 2022-11-24 22:49:59 UTC
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?
Comment 8 Holger Hoffstätte 2024-02-21 13:59:21 UTC
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.
Comment 9 Holger Hoffstätte 2024-02-21 15:50:54 UTC
(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