Alan Cox wrote:
>
> > are 'legal' at both the user and kernel level (UID==65535 is legal). UID==0 is not
> > special in regards to auditing.
>
> 65535 is special as is 2^32-1. (uid_t)-1 (ie the unsigned cast of in our case)
> is special to setuid and related calls meaning 'no change'
--- Uh...I wasn't able to create a user with UID == -1, but I was able to create a user with UID 65535 and login worked -- did an 'id' command after logging in and it said I was id 65535. I can also 'su' to the name:(this is on a 2.2.14 kernel, SuSE 6.3 distro).
# su test bash-2.03$ id uid=65535(test) gid=100(users) groups=100(users) bash-2.03$
> > > 1) adding a variable "luid" to the uid_t line in the task struct > > 2) adding two system calls - 1 to 'set' and one to 'get' the value. > > 3) adding CAP_SET_LUID that allows setting setting the luid. > > > > This proposal would affect no user applications in current systems. It > > would be tamperproof on current systems by anyone not possessing CAP_SET_LUID. > > Untrue. All users must lack CAP_SYS_RAWIO for this to be true, otherwise they > can use hardware to DMA back over their luid from other capabilities --- Uh yeah....very true -- I'm sure their are various CAP's one could use to subvert the mechanism. Being 'root', with no CAP's, I could probably write to /dev/mem or /dev/kmem I would think. So we can't get too smug about protection. But minimum privilege is still a great idea...:-)
-l
...so...I don't get it...why does UID==65535 work? Maybe parts of the kernel are already treating it as 32-bit?
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:08 EST