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: http://www.gmx.net/de/go/freephone
Home |
Main Index |
Thread Index |
Old Index