[lkml]   [2002]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: problems with changing UID/GID
On Tuesday 27 August 2002 22:01, Chris Wedgwood wrote:
> On Tue, Aug 27, 2002 at 09:35:10PM +0200, Trond Myklebust wrote:
> Locking does absolutely nothing for the problem of checking file
> access with one set of credentials, and then doing the subsequent file
> operation with another set of credentials.
> Can we not lock creds at the syscall level? Ick... shoot me for saying
> this :)

Ick indeed... That sounds pretty nasty now that we have SMP and preemptive

I've restarted work on the alternative: putting basic BSD ucreds + VFS changes
in first. It's a lot of work, but I think it will be worth it.

FYI a BSD ucred is basically a structure of the form

struct ucred {
int counter; /* Reference counter */
uid_t uid; /* task->fsuid */
gid_t gid; /* task->fsgid */
int ngroups; /* task->ngroups */
gid_t *groups; /* task->groups */

The reference counter + the copy-on-write rule allows you to share it around
to other parts of the kernel (struct file, low level filesystems, ...). By
copy-on-write I mean that once it has been shared, nobody is allowed to
change the values of the data structures (except the reference counter).

Means that you don't need any form of locking for this structure apart from
perhaps in those rare CLONE_CRED instances when you are actually changing the
shared ucred in the task_struct for all the threads.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.226 / U:16.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site