uid & UnixLib

John Tytgat 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
"program").

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 ?

Regards,
John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven




More information about the gcc mailing list