lkml.org 
[lkml]   [1998]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: High UID support for Linux
Peter Benie wrote:
> That's interesting, because not all the filesystems support high uids.
> I wonder what happens to a setuid 65536 file on a minix V1 filesystem?

All the FSes will have to support 32-bits _in_the_kernel_. This shouldn't
be a problem.

On disk, the only real issue is chown(2) and friends. They can return
-EINVAL if they can't change the UID to that value. This appears to be
what Solaris does (although I'm not sure what filesystems it would affect...
the man page for chown(2) mentioned "EINVAL group or owner is out of range".

For access(2) tests, there are no special semantics needed. A high uid
just won't be ever able to own a file on a low-uid filesystem.
Unfortunately, this also implies that you can't creat(2) files.

> __u16 had been used in
> APIs, which makes the transition to 32bit uids a little painful.

Quite.

> - what happens when you use a 16bit fs with a uid>=65535?

Again, nothing special, it's just that you can't own any files.

> - what happens when you use a system call with a 16bit uid when your
> uid is >=65535.

Probably -EPERM or -EINVAL.

> It doesn't look like that much work to implement, but it's definately
> a 2.3 project.

Absolutely. Early in 2.3 we should expand almost all the types (uid_t,
gid_t, pid_t, off_t, ...).

-Mitch

-
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/

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