Bug 215926

Summary:	capsh --user=xxx generates errors for bash
Product:	Tools	Reporter:	Andrew G. Morgan (morgan)
Component:	libcap	Assignee:	Andrew G. Morgan (morgan)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	o
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	n/a	Subsystem:
Regression:	No	Bisected commit-id:

Description Andrew G. Morgan 2022-04-30 23:00:00 UTC

All versions of capsh that support the --user argument generate some complaints from bash when changing user. For example:

$ sudo /sbin/capsh --user=$(whoami) --
bash: /root/.bashrc: Permission denied
$ 

I've been looking into this and it appears that what is going wrong is capsh is not fixing up the HOME environment variable when the user ids are changed. Bash uses what it gets for HOME, and since the sudo wrapper has set HOME to /root the resulting error makes sense.

I'm filing this bug so I can reference it in the https://sites.google.com/site/fullycapable/inheriting-privilege article. When I originally wrote that, I chose not to dig into why it happened and found a workaround to use in the examples. One such example was this:

$ sudo capsh --user=$(whoami) --iab='^cap_setuid' -- --norc

The --norc argument (supplied to bash) skips trying to parse /root/.bashrc so that muted the error.

I'm going to modify capsh to, by default, change USER and HOME environment variables when --user= is specified. I'm going to provide an override for this that will resurrect the annoying legacy behavior. To do this, you should precede  --user with --noenv.

After I've released the next libcap (it will be libcap-2.65 release date undecided) this error will no longer be present. I'll also trim that article to not use the --norc flag. (It is that documentation change that I want to point back to this bug for an explanation.)

Comment 1 Andrew G. Morgan 2022-04-30 23:30:09 UTC

This is fixed with (which will be included in libcap-2.65):

https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=eb0f1df722d5e760137a0dd85fee8e78c95ee68f

I'm going to leave this bug open until after libcap-2.65 is actually released (no ETA). At that time, I'll fix the article mentioned above and close this bug.

Comment 2 Ozgur Kara 2022-05-01 10:44:29 UTC

Hello,

this seems to be bundled with libcap2 and bug may be fixed with next libcap2 release I think, oh I see you have released a patch now, thanks :)

Comment 3 Andrew G. Morgan 2022-07-18 00:02:56 UTC

I've updated the article mentioned in #1:

  https://sites.google.com/site/fullycapable/inheriting-privilege