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 1 vote (vote)
Assignee: Sven Wegener
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-21 07:47 UTC by Hanno Böck
Modified: 2021-10-13 01:29 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? :(