Messages in this thread |  | | From | Trond Myklebust <> | Subject | Re: problems with changing UID/GID | Date | Wed, 28 Aug 2002 00:09:03 +0200 |
| |
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 kernels.
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.
Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |