I had asked if the uucp uid was hardcoded into the uucico program
under SUNOS 4.1.x (complete original message below). The "definitive"
answer from Guy Harris (guy@auspex.com) was yes:
> Is this really hardcoded into the uucico program (i.e. it must
> have been some sort of compile time option).
> Yup. Dunno whether the idea came from honey, dan, ber, or somebody in
> Summit, but I think that's the way it came (that's the way the SVR3.0
> UUCP works, for example).
The generic question on how to easily merge password files between two
"incompatible" systems still remains.
Thanks,
--G
--
Guntram Wolski gwolsk@sei.com
Sequoia Semiconductor, Inc. 408-438-5331 x112
...!{mips,ames}!seidc!gwolsk
------- Start of forwarded message -------
In an attempt to merge passwd files between mips RISCos 4.52
and SUNOS 4.1.x the uid of our 'uucp' account became 5. The standard
SUN supplied account number in the passwd file is 4. When I run
/usr/lib/uucp/uucico as root using trace one of the first things that
happens is a call to 'setreuid(4,4)' This is to set the user id and the
effective user id to 4! Not the value of the uucp account. For some
reason my uucp seems to work most of the time, I just happened to
notice that it was not having success in opening files further on
(they are of course owned by my uucp account with uid 5).
The question is:
Is this really hardcoded into the uucico program (i.e. it must
have been some sort of compile time option). Or is the setreuid()
call being handled in a way that I don't understand.
Any help on this (or in merging the passwd files of these two systems)
would be appreciated. This all comes about since occasionally my
system gets into a weird state where I can not tip to it ("all ports
busy") even though nothing is using it (for some reason my systems
don't have fuser so I can't tell who/what the kernel thinks is using
it -- at least not easily.)
Thanks,
- --G
- --
Guntram Wolski gwolsk@sei.com
Sequoia Semiconductor, Inc. 408-438-5331 x112
...!{mips,ames}!seidc!gwolsk
------- End of forwarded message -------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:40 CDT