uid & UnixLib
John.Tytgat at aaug.net
Mon Dec 22 11:30:44 PST 2003
In message <fd5776634c.peter at chocky.org>
Peter Naulls <peter at chocky.org> wrote:
> In message <f05f75634c.Jo at hobbes.bass-software.com>
> John Tytgat <John.Tytgat at aaug.net> wrote:
> > Does anybody know why the latter only happens when the Unix$uid value is
> > non-zero ? I.e. why not allow UnixLib compiled program to be run as "root"
> > if the user really wants that ? On RISC OS this does not make any
> > difference at all.
> That does seem wrong, yes. But certainly, it should not run as "root"
> by default, since some programs complain.
I have an upcoming patch to address this. Before I commit this, I would
like to have some feedback on the idea to change the environment
variable "Unix$uid" into an UnixLib "feature" (just like we have the
"nonametrans" and "sfix" features). This means that "Unix$uid" gets
renamed to "UnixEnv$uid" (acting for all UnixLib programs) or
to "UnixEnv$program$uid" (acting only for UnixLib programs with leafname
Also, there is such a thing called "Unix$tty" which specifies the
"terminal file program" (cfr ReadMe36c1 and ReadMe36c2). Typically set
to /dev/serial or /dev/null I guess. I don't see any valid use cases for
this because we can archieve the same by proper command line redirection.
Any objections to remove the "Unix$tty" support code ?
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc