Mailing List Archive

Re: Hard coded UIDs revisited
> Do these compiler-less systems come with adb? I ask because one way to
> handle the special uids might be to declare them as global ints instead
> of manifest constants, and use adb or a similar tool to patch them at
> install time. String valued constants could be handled similarly, but
> you'd have to watch out for overflow, of course. Also, there's the
> problem of making sure that all the installed binaries really do have
> the right stuff patched in.
>
> Anyway, is this a workable compromise?

Editing the binaries? I think not.


--Donnie

--
Donnie Barnes http://www.redhat.com/~djb djb@redhat.com "Bah."
See http://www.LinuxExpo.org for info on the biggest Linux event ever!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
_Things You'd NEVER Expect A Southerner To Say_ by Vic Henley:
** Yes, I realize that I'm suppressing my inner child.
Re: Hard coded UIDs revisited [ In reply to ]
>> Anyway, is this a workable compromise?

>Editing the binaries? I think not.

If the editing of the binaries is done by the installation script,
what is wrong with it?
Re: Hard coded UIDs revisited [ In reply to ]
Donnie Barnes writes:
>
> > Do these compiler-less systems come with adb? I ask because one way to
> > handle the special uids might be to declare them as global ints instead
> > of manifest constants, and use adb or a similar tool to patch them at
> > install time. String valued constants could be handled similarly, but
> > you'd have to watch out for overflow, of course. Also, there's the
> > problem of making sure that all the installed binaries really do have
> > the right stuff patched in.
> >
> > Anyway, is this a workable compromise?
>
> Editing the binaries? I think not.

Well, what's the difference between editing the binaries at compile
time vs install time vs load time (say, by a small dynamic library
containing the config values) vs run time? Either way, we are causing
a particular value to be deposited in memory. The method we choose
should be one that meets all our goals.

What *are* our goals anyway? I think that's the real problem.
Various people have different unarticulated goals.

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)
Re: Hard coded UIDs revisited [ In reply to ]
> What *are* our goals anyway? I think that's the real problem.
> Various people have different unarticulated goals.

I think most of "us" would like qmail not to go its own path in this
area. When it wants to know the uid for a username, it should use
getpwnam() at run time, just like every other program. Then Red Hat
can determine what uids qmail uses the normal way: it can edit
/etc/passwd and chown the binaries. And, as someone else noted,
people won't need root access on their build machines just to produce
a set of qmail binaries.
Re: Hard coded UIDs revisited [ In reply to ]
On Thu, 6 Feb 1997, Icarus Sparry wrote:

> If the editing of the binaries is done by the installation script,
> what is wrong with it?
>
because it makes your packaging system (RPM, for instance) unable to
reliably verify whether the installed binaries are ok

--Pavel Kankovsky aka Peak (troja.mff.cuni.cz network administration)
Re: Hard coded UIDs revisited [ In reply to ]
i'm sure we're not voting here but i'm not in that ``most of "us"''. in
some environments the next to the last thing you want to do is search a big
file but the last thing you want to do is envoke nis/nis+.

>>>>> "Greg" == Greg Hudson <ghudson@MIT.EDU> writes:

Russell> What *are* our goals anyway? I think that's the real problem.

Greg> I think most of "us" would like qmail not to go its own path in
Greg> this area. When it wants to know the uid for a username, it
Greg> should use getpwnam() at run time, just like every other program.

--
paul
pjg(at)acsu.Buffalo.EDU |public keys at:
| http://urth.acsu.Buffalo.EDU/~pjg/key.html
if the above contains opinions they are mine unless marked otherwise.
Re: Hard coded UIDs revisited [ In reply to ]
Paul Graham writes:
> i'm sure we're not voting here but i'm not in that ``most of "us"''. in
> some environments the next to the last thing you want to do is search a big
> file but the last thing you want to do is envoke nis/nis+.
>
> >>>>> "Greg" == Greg Hudson <ghudson@MIT.EDU> writes:
>
> Russell> What *are* our goals anyway? I think that's the real problem.
>
> Greg> I think most of "us" would like qmail not to go its own path in
> Greg> this area. When it wants to know the uid for a username, it
> Greg> should use getpwnam() at run time, just like every other program.

Let's stick to goals, and leave implementation for later.

Paul says that he wants to avoid examining /etc/passwd, and especially nis/nis+.

Dan's goal (not to speak for him, but to write down my recollection of
what he has said) is to stay away from linking any C library
code into a qmail executable, and to avoid getpw*, since they
have no way to report temporary failures and are hence
unreliable.

Greg's goal is to stick with standard unix methods.

Donnie's goal is to be able to ship a set of binaries which will work
on EVERY Redhat system, existing or new. Since Redhat's
package manager can do cryptographic verification of
integrity, I expect that he further wants the binaries to
remain unmodified.

My goal is to not require compilation of qmail to configure it. By
the way, I had to do an emergency upgrade (important users
complaining about mail not getting through to a host with bad
nameserver data) to 0.96. I forgot to change conf-unusual, so
mail was going into ./Mailbox by default instead of ./Maildir/.

Any other goals?

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)
Re: Hard coded UIDs revisited [ In reply to ]
why can't qmail-send use qmail-getpw at start time to get these
UID values from `the password file' ? that way, _nothing_ is
linked differently, qmail-send gets to keep out of the C library,
yadda yadda yadda.