I started looking into this this summer. My idea was to move
the credentials into a "struct cred", pointed to from the
task struct. A "struct cred" would be reference counted and
be mutable or immutable. I had three goals with this:
1. Ensure that a group of threads executing within a single
heavyweight process would share credentials.
These tasks would share the same "mutable" cred struct.
2. Reduce the size of the task struct, and speed up fork
and exit by replacing some copying operations with simple
reference count adjustments.
If a group of processes descending from a common parent
are going to have the same credentials, it may make sense
to let them share the same "struct cred". The idea being
that fork/exit could trade some memory allocation and
copying overhead for simple reference count adjustments.
Such a shared "struct cred" would be "immutable",
so if some process in the group changes uid for instance,
then it would be given a private "struct cred" first.
A private "struct cred" is simply a "mutable" one with
a reference count of 1, and updating a private "struct cred"
just changes the fields, like we do now.
3. Simplify the passing of SCM_CRED messages over Unix-domain
sockets. The messages would just keep a reference to the
"struct cred", w/o any copying.
However, there are places in the kernel where the kernel itself
makes temporary adjustments to a task's credentials, for instance
in fs/open.c:sys_access(). [This is the one culprit I can
remember right now, but there's also one in NFS I think.]
Until this is fixed, there's no point in tasks sharing the same
"struct cred": In the case of multiple threads in a heavyweight
process, the other threads would immediately see the change.
In the case of speeding up fork/exit, the gain from avoiding
the copy is nullified the instant the process makes some system
call that makes temporary adjustments to the credentials.
The first problem doesn't occur if credential changes are
broadcast instead of being physically shared.
Both problems could be fixed if the relevant procedures in the
kernel would take explicit "effective credentials" parameters
instead of retrieving them from the task struct.
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/