Messages in this thread | | | Date | Fri, 27 Nov 1998 10:01:55 -0500 (EST) | From | "J. S. Connell" <> | Subject | Re: High UID support for Linux |
| |
On 27 Nov 1998, Andreas Schwab wrote:
> They will just use getenv("HOME"). No need for uid.
$HOME isn't always set[1], and some existing programs do getpwuid(getuid())->pw_dir[2]. Sure, you can argue that they need fixing, but having to "fix" the program involves recompiling the program, and if you can recompile the program, it will be recompiled with the extended getpwuid()/getuid()/etc. calls and won't be a problem any more. Doesn't help if you happen to need a binary for which you've lost the source[3] or can't get source.
It's been a long time since I've done much source-level hacking on random userspace programs, and I'm therefore unlikely to have much of a feel anymore for what programs really do to find your home directory.
I'm not advocating the kludge here. Frankly, I don't know what the Right Answer(tm) is to extending uid_t to 32 bits *and* keeping backwards compatibility.
[1]Rare, but can happen. [2]E.g., if $HOME isn't set, or if the program is setuid and doesn't trust $HOME. [3]Like the online password changer at the last ISP I worked for. Worked fine (mostly), but would have needed to be rewritten from scratch as soon as we used uid 65536. Not impossible, but not trivial, given the Byzantine system we had. =)
-- Jeffrey Sean Connell | Networking/Telecommunications Engineer, GXC ankh@canuck.gen.nz | PGP key at http://www.canuck.gen.nz/~ankh/pgpkey.html ---------------------+-------------------------------------------------------
- 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/
| |