2

I was debugging kcheckpass under Archlinux. (Because I failed to login with kcheckpass)

Somehow I believe this particular problem is not within kcheckpass.

int
main(int argc, char **argv)
{
#ifdef HAVE_PAM
  const char    *caller = KSCREENSAVER_PAM_SERVICE;
#endif
  const char    *method = "classic";
  const char    *username = 0;
#ifdef ACCEPT_ENV
  char      *p;
#endif
  struct passwd *pw;
  int       c, nfd, lfd;
  uid_t     uid;
  time_t    nexttime;
  AuthReturn    ret;
  struct flock lk;
  char fname[64], fcont[64];

  // disable ptrace on kcheckpass
#if HAVE_PR_SET_DUMPABLE
  prctl(PR_SET_DUMPABLE, 0);

Before the execution of the very first line: prctl(PR_SET_DUMPABLE, 0);

ls /proc/$(pidof kcheckpass)/exe  -al
lrwxrwxrwx 1 wuyihao wuyihao 0 Jan 16 16:16 /proc/31661/exe -> /cker/src/build/kcheckpass/kcheckpass

And after executing it:

ls /proc/$(pidof kcheckpass)/exe  -al
ls: cannot read symbolic link '/proc/31661/exe': Permission denied

The same with /proc/31661/root and /proc/31661/cwd

I don't see any connection between coredump and read permission of /proc/$PID/exe

UPDATE

Minimal example reproduced this problem:

#include <sys/prctl.h>
#include <stdio.h>
int main(){
    prctl(PR_SET_DUMPABLE, 0);
    return 0;
}

UPDATE2 kcheckpass and minimal example test are both:

-rwsr-xr-x 1 root root

  • BTW, I got my kcheckpass working, by reinstall libpam. – wuyihao Jan 16 '17 at 10:39
2

When you remove the dumpable attribute, a bunch of /proc/<pid>/ files and links becomes unreadable by other processes, even owned by the user.

The prctl manpage reads:

Processes that are not dumpable can not be attached via ptrace(2) PTRACE_ATTACH; see ptrace(2) for further details.

If a process is not dumpable, the ownership of files in the process's /proc/[pid] directory is affected as described in proc(5).

And the proc manpage reads:

/proc/[pid]

Each /proc/[pid] subdirectory contains the pseudo-files and directories described below. These files are normally owned by the effective user and effective group ID of the process. However, as a security measure, the ownership is made root:root if the process's "dumpable" attribute is set to a value other than 1.

And finally, the ptrace manpage reads:

Ptrace access mode checking

Various parts of the kernel-user-space API (not just ptrace() operations), require so-called "ptrace access mode" checks, whose outcome determines whether an operation is permitted (or, in a few cases, causes a "read" operation to return sanitized data).

(...)

The algorithm employed for ptrace access mode checking determines whether the calling process is allowed to perform the corresponding action on the target process. (In the case of opening /proc/[pid] files, the "calling process" is the one opening the file, and the process with the corresponding PID is the "target process".) The algorithm is as follows:

(...)

  1. Deny access if the target process "dumpable" attribute has a value other than 1 (...), and the caller does not have the CAP_SYS_PTRACE capability in the user namespace of the target process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.