Thomas Lockhart wrote:
>
> > Joel Burton suggested the rserv utility. I don't know how well it would
> > work over a wide network.
>
> It should work well over a WAN for what it can do. However, that is
> async one-way replication, which was not your initial requirement.
>
> Of course, requirem
This call
setuid(geteuid());
is found in backend/utils/init/postinit.c. AFAICT, this does nothing.
Anyone got an idea?
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 1: subscribe and un
> This call
>
> setuid(geteuid());
>
> is found in backend/utils/init/postinit.c. AFAICT, this does nothing.
> Anyone got an idea?
Well, from my BSD manual it says:
The setuid() function sets the real and effective user IDs and the saved
set-user-ID of the current process to the spe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> so it seems to make sure the real/saved uid matches the effective uid.
> Now, considering we don't use uid/euid distinction for anything, I agree
> it is useless and should be removed.
No, it is NOT useless and must NOT be removed. The point of this l
>> so it seems to make sure the real/saved uid matches the effective uid.
>> Now, considering we don't use uid/euid distinction for anything, I agree
>> it is useless and should be removed.
> No, it is NOT useless and must NOT be removed.
But it would make sense to move it over to main.c where
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > so it seems to make sure the real/saved uid matches the effective uid.
> > Now, considering we don't use uid/euid distinction for anything, I agree
> > it is useless and should be removed.
>
> No, it is NOT useless and must NOT be removed. The poi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I understand, but how do we get suid execution. Does someone have to
> set the seuid bit on the executable?
Probably so, but I could see someone thinking they could do that as a
substitute for saying "su - postgres" on every startup.
If we are going t
Tom Lane writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > so it seems to make sure the real/saved uid matches the effective uid.
> > Now, considering we don't use uid/euid distinction for anything, I agree
> > it is useless and should be removed.
>
> No, it is NOT useless and must NOT be r
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I understand, but how do we get suid execution. Does someone have to
> > set the seuid bit on the executable?
>
> Probably so, but I could see someone thinking they could do that as a
> substitute for saying "su - postgres" on every startup.
>
> I
> That is a valid concern, but the code doesn't actually prevent this. I
> just tried
>
> chmod u+s postgres
> su -
> postmaster -D ...
>
> Then loaded the function
>
> #include
>
> int32 touch(int32 a) {
> if (setuid(0) == -1)
> elog(ERROR, "setuid: %m");
> elog(DEBUG, "getu
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> We want real uid
>> to become postgres as well --- otherwise our test to prevent execution
>> as root is a waste of time, because nefarious code could become root
>> again just by doing setuid. See the setuid man page: if real uid is
>> root then se
I said:
> On machines that have setreuid(), or even better setresuid(), we could
> force the ruid (and suid for good measure) to match euid. Otherwise we
> probably should refuse to start unless getuid matches geteuid.
But on third thought, it's not worth the trouble of adding two more
configure
Tom Lane writes:
> I said:
> > On machines that have setreuid(), or even better setresuid(), we could
> > force the ruid (and suid for good measure) to match euid. Otherwise we
> > probably should refuse to start unless getuid matches geteuid.
>
> But on third thought, it's not worth the trouble
> > That is a valid concern, but the code doesn't actually prevent this.
>
> After reading the setuid man page a third time, I think you are right.
>
> On machines that have setreuid(), or even better setresuid(), we could
> force the ruid (and suid for good measure) to match euid. Otherwise we
> I said:
> > On machines that have setreuid(), or even better setresuid(), we could
> > force the ruid (and suid for good measure) to match euid. Otherwise we
> > probably should refuse to start unless getuid matches geteuid.
>
> But on third thought, it's not worth the trouble of adding two mo
> Tom Lane writes:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > so it seems to make sure the real/saved uid matches the effective uid.
> > > Now, considering we don't use uid/euid distinction for anything, I agree
> > > it is useless and should be removed.
> >
> > No, it is NOT useless a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> so why does your test work? Does your manual say something different?
>> If setuid() sets user/effective/saved to postgres, how can you get back
>> root?
> : setuid sets the effective user ID of the current process. If t
Bruce Momjian writes:
> so why does your test work? Does your manual say something different?
> If setuid() sets user/effective/saved to postgres, how can you get back
> root?
: setuid sets the effective user ID of the current process. If the
: effective userid of the caller is root, the re
> HPUX has an even more bizarre definition:
>
> setuid() sets the real-user-ID (ruid),effective-user-ID (euid), and/or
> saved-user-ID (suid) of the calling process. The super-user's euid is
> zero. The following conditions govern setuid's behavior:
>
> o If the euid
19 matches
Mail list logo
