tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Addition to kauth(9) framework

> Both options sound wrong to me, what did I misunderstand?

Ok. I'll try to explain.
1) kauth_cred_t is shared between different processes
   for performance reason. Every new kauth_cred_t owner
   increases embedded reference count
   of this structure. When it is not needed anymore, its owner
   calls kauth_cred_free decreasing refcounter by 1.
   When it becomes 0, kauth_cred_t is freed.
2) securechroot(9) I proposed some time ago adds some
   extra information (root directory) to kauth_cred_t
   structure (held by all chrooted processes) with
   a help of KAUTH_CRED_CHROOT message sent by
   chroot/fchroot syscalls. Plain fork(2) doesn't create new
   kauth_cred_t instances, so child processes
   shares the same instance of kauth_cred_t.
   Listener of KAUTH_CRED_CHROOT is securechroot(9) module.
3) When credentials are changed by setuid(2)/setgid(2) etc.,
   new instance of kauth_cred_t is created, original credentials
   are copied to new instance and refcounter is set to 1
   (In this thread people call this "unsharing",
     see kauth_cred_dup and kauth_cred_copy).
4) kauth_cred_setdata is used to set root directory
   in kauth_cred_t, this information is used to
   determine what kind of things the process is able
   to do/see/change/access etc.
   kauth_cred_setdata modifies given instance of kauth_cred_t.
   So, if it is shared between several processes, all they will
   be affected by securechroot(9), even if they are not chrooted.
   Due to this chrooted process needs new instance,
   with refcounter reset to 1.

The question is *where* new kauth_cred_t instance
should be created and assigned to the process:
1) Inside chroot/fchroot(2) (this is in my patch)
2) Modules that adds "credential private data".

NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!               
Jetzt informieren:

Home | Main Index | Thread Index | Old Index