Thomas Adam <thomas@xteddy.org> writes:

> On Fri, Sep 24, 2021 at 11:16:36PM +0200, Omar Polo wrote:
>
> Hey Omar.  Thanks for your work on this, it looks really interesting.
>
>> I haven't find out how to obtain the rpath programmatically.  It would
>> surely fix the issue thought.  (I'm manually adding /lib64 *just for
>> testing* and it works.)
>
> Does the following help?  It took me a few moments to find the relevant
> comments in source files to cobble this together:
>
> 	#include <stdio.h>
> 	#include <link.h>
> 	#include <elf.h>
>
> 	int main(void)
> 	{
> 		const char 	*stab = NULL;
> 		const ElfW(Dyn) *dyn = _DYNAMIC, *rpath = NULL;
>
> 		for (; dyn->d_tag != DT_NULL; dyn++) {
> 			if (dyn->d_tag == DT_RPATH) {
> 				rpath = dyn;
> 			} else if (dyn->d_tag == DT_STRTAB)
> 				stab = (const char *)dyn->d_un.d_val;
> 		}
>
> 		if (stab != NULL && rpath != NULL)
> 			printf("Found rpath: %s\n", stab + rpath->d_un.d_val);
>
> 		return (0);
> 	}
>
> Gives:
>
> $ gcc -o rpathtest rpathtest.c -Wl,-rpath,/tmp/foo
> $ ./rpathtest
> Found rpath: /tmp/foo

It's very similar to what I've come up to.  I forgot to include
-Wl,-rpath when compiling the executable and so it was missing.

However, I don't see any -Wl,-rpath,... when compiling got, neither on
OpenBSD nor on linux.

I was even thinking of trying to parse the elf header.  On linux I
should find the current executable on /proc/self/exec, and from there
with helps from elf.h I should be able to understand if it's a static
executable or where are the needed libs.  It could help when/if got and
the libexec helpers ends up being linked to different libraries.  I
never did something like that but seems fun :)

Anyway, I don't know much of how linking works, so I have no idea of how
what I'll find in the elf header plays with rpath, LD_LIBRARY_PATH
and/or LD_PRELOAD.

[ all this mess is only needed to simulate unveil in got/got.c.  Locking
  down the libexec helpers is much, much easier and is already working ]

> [...]
>
>> I think I've addressed this too.  I've added compat/landlock.c that's
>> conditionally linked in the build if HAVE_LINUX_LANDLOCK.
>
> I was wanting to see this tied to the PLATFORM as this is Linux-specific.  But
> no problem, I can adjust that.  What you have is fine though.

Right, you even mentioned in the previous mail the makefile snippet,
apologies.

> In terms of the patch itself, it looks fine, although my system here is not
> landlock-aware, so I will need to go updating the kernel, etc., to get it to
> be.  That'll be fun!

slightly OT, but if you find how to obtain a working linux/landlock.h
header on arch/void/alpine I'd be interested.  Those distro ship linux
5.14+ now, but their linux-headers package doesn't contain that header,
only /something/something/uapi/linux/landlock.h which can't be included
from the quick tests I did.

fedora has a linux/landlock.h header.  I don't know about other distros.

> Please keep sending the patches over.  I'll be publishing a "landlock" branch
> in got-portable in just a moment for you to reference as go along...

Thanks!

> Kindly,
> Thomas

Cheers!

Omar Polo