This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add UNSUPPORTED check in elf/tst-pldd.



On 27/08/2019 12:14, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> This is a Linuxism and I think we should create a 'support_can_ptrace'
>> similar to 'support_can_chroot'.  The logic to detect it seems
>> correct, I would just check fscanf returned to value and use xfclose.
>> It would be something like
> 
> The test does the right thing if the path does not exist, so I'm not
> sure if it is necessary.

Even though, a check for a Linux specific path should be restricted to
Linux builds only.

> 
> support_can_ptrace would be misleading because even with YAMA scope
> support, tracing direct subprocesses will still work.

Indeed, a better prototype would be indeed:

/* Return the current YAMA mode set on the machine (0 to 3) or -1
   if YAMA is not supported.  */
int support_ptrace_scope (void);

> 
> I fact, I think we might be able to get this test to work even with
> fairly restrictive YAMA scopes, by proper ordering of forks and using
> execve to run tst-pldd.

The problem with ptrace_scope 1 is tst-pldd will either make its fork 
helper process a pldd descendant or pass pldd pid to the forked process 
so it can call prctl (PR_SET_PTRACER, ...).  In either case I am not 
really sure it is possible without change pldd process itself (since 
it does not have an interactive mode), nor if the complexity to support 
this specific scenarios pays off. 

The ptrace_scope 2 is even more tricky since it requires CAP_SYS_PTRACE.

In any case I think by restricting the test to run on ptrace_scope 0
is a fair assumption.

> 
> Thanks,
> Florian
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]