Re: Initdb fails... Again!

Hi!

It seems I have worked around the problem, "ipctest s" started working
"out of blue", when I had ipc-daemon running background. Running as
service didn't help as it was mentioned in previus postings.

After that, initdb went ok. Then I killed the background ipc-daemon.
Postmaster seems to be happy with ipc-daemon's service version.

Anyway, it seems to work at last, thank you for very much!

Markko

> Please take this problem to the Cygwin list
> <cygwin(at)cygwin(dot)com> because I must be missing something.
> Also, I hope that the cygipc maintainer will chime in too.
> My suggestion is to focus on the ipctest problem instead of
> PostgreSQL. However, I think that it is OK to mention that
> PostgreSQL is affected too.
>
> Thanks,
> Jason
>
> --
> PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
> Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
>

Markko,

On Wed, Jan 22, 2003 at 04:38:37PM +0200, Markko Paas wrote:
> It seems I have worked around the problem, "ipctest s" started working
> "out of blue", when I had ipc-daemon running background. Running as
> service didn't help as it was mentioned in previus postings.
>
> After that, initdb went ok. Then I killed the background ipc-daemon.
> Postmaster seems to be happy with ipc-daemon's service version.

Hmm...I recommend getting to the bottom of this because it may stop
working "out of blue" sometime in the future.

> Anyway, it seems to work at last, thank you for very much!

You are quite welcome.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Markko and Jason,

Jason Tishler wrote:
> On Wed, Jan 22, 2003 at 04:38:37PM +0200, Markko Paas wrote:
>
>>It seems I have worked around the problem, "ipctest s" started working
>>"out of blue", when I had ipc-daemon running background. Running as
>>service didn't help as it was mentioned in previus postings.
>>
>>After that, initdb went ok. Then I killed the background ipc-daemon.
>>Postmaster seems to be happy with ipc-daemon's service version.
>
>
> Hmm...I recommend getting to the bottom of this because it may stop
> working "out of blue" sometime in the future.

I had a very similar experience: sometimes postgres started, sometimes not.

It turned out that the "postgres" user must have write permissions to
/tmp/MultiFileSem, otherwise both postgres and ipctest fails (when run
from the postgres account).

ipc-daemon creates this file with -rw-r--r-- permissions on my machine.
That means that if ipc-daemon is run from the postgres account when this
file is missing, it will be writable by postgres and all is fine (even
if ipc-daemon is later run as, say, SYSTEM or root by cygrunsrv).

However, if /tmp/MultiFileSem isn't around when ipc-daemon is run as a
service, a new file will be created that is owned by SYSTEM, and hence
not writable by postgres.

So the solution is to either say
chmod a+w /tmp/MultiFileSem
or
chown postgres /tmp/MultiFileSem
before starting postmaster. Probably not a brilliant solution, security
wise, but the only solution I've found.

/dan

Dan,

On Wed, Jan 22, 2003 at 11:05:39PM +0100, Dan Holmsand wrote:
> Jason Tishler wrote:
> >Hmm...I recommend getting to the bottom of this because it may stop
> >working "out of blue" sometime in the future.
>
> I had a very similar experience: sometimes postgres started, sometimes
> not.

Your problem may be not quite the same as Markko's, because the
permissions of his /tmp/MultiFile* files were "-rw-rw-rw-".

> It turned out that the "postgres" user must have write permissions to
> /tmp/MultiFileSem, otherwise both postgres and ipctest fails (when run
> from the postgres account).

Yes, the client user must have write access in order for cygipc to
function properly.

> ipc-daemon creates this file with -rw-r--r-- permissions on my
> machine.

What is the permissions of /tmp?

$ ls -ld /tmp
drwxrwxrwx+ 111 Administ Domain U 221184 Jan 24 06:49 /tmp

If they are not 777, then execute:

$ chmod 777 /tmp
$ rm -f /tmp/MultiFile*

and restart ipc-daemon as a service.

Are the permissions of /tmp/MultiFile* writable by all now?

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason,

Jason Tishler wrote:
> Your problem may be not quite the same as Markko's, because the
> permissions of his /tmp/MultiFile* files were "-rw-rw-rw-".

Sorry, I didn't know that (I just saw that your permissions were set
that way - that's what made me think of the difference).

> What is the permissions of /tmp?
>
> $ ls -ld /tmp
> drwxrwxrwx+ 111 Administ Domain U 221184 Jan 24 06:49 /tmp
>
> If they are not 777, then execute:
>
> $ chmod 777 /tmp
> $ rm -f /tmp/MultiFile*
>
> and restart ipc-daemon as a service.
>
> Are the permissions of /tmp/MultiFile* writable by all now?

I think I've found the problem. Yes, /tmp is 777, but I had run
ipc-daemon with a umask of 022 (the default in cygwin these days).
Apparently, ipc-daemon doesn't set umask itself, so the MultiFiles
become -rw-r--r--.

Rerunning ipc-daemon as a service (installed with ipc-daemon
--install-as-service) fixes this (umask seems to be 000 in this case),
but only if you've deleted the MultiFiles first.

So, as soon as ipc-daemon has been run with a non-000 umask by a user
that is not "postgres" (e.g. manually or from a sysv start script
(currently my favourite way of running ipc-daemon and postgres)),
postgres fails to start, even after restarting ipc-daemon as a service.

/dan

Dan,

On Fri, Jan 24, 2003 at 05:51:09PM +0100, Dan Holmsand wrote:
> So, as soon as ipc-daemon has been run with a non-000 umask by a user
> that is not "postgres" (e.g. manually or from a sysv start script
> (currently my favourite way of running ipc-daemon and postgres)),
> postgres fails to start, even after restarting ipc-daemon as a
> service.

Thanks for taking the time to track down the above issue.

BTW, by "sysv start script" do you mean using the sysvinit package. If
so, then how did you get around the following issues:

http://www.cygwin.com/ml/cygwin/2002-11/msg00669.html
http://www.cygwin.com/ml/cygwin/2002-11/msg00677.html
http://www.cygwin.com/ml/cygwin/2002-11/msg00838.html

Thanks,
Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason,

Jason Tishler wrote:
> BTW, by "sysv start script" do you mean using the sysvinit package. If
> so, then how did you get around the following issues:
>
> http://www.cygwin.com/ml/cygwin/2002-11/msg00669.html
> http://www.cygwin.com/ml/cygwin/2002-11/msg00677.html
> http://www.cygwin.com/ml/cygwin/2002-11/msg00838.html

Yeah, sysvinit and initscripts. I've been hoping something like that
would show up in cygwin for quite some time, so I've struggled a bit to
make it work.

First, sysvinit (I think) installed a bad inittab (without runlevel
support). Reinstall fixed this.

Second, su didn't work (I thought), so I started hacking together a
working su.

But then I noticed that su actually *does* work if a privileged enough
user with uid 0 (i.e. "root") runs it. So now I'm running /sbin/init as
a service as "root", after assigning all the necessary privileges to
"root" ("Run as part of the operating system", etc). You have to edit
/etc/passwd by hand to make sure root gets uid 0.

Third, you have to get some start scripts. In particular you have to
make sure that they create/delete a /var/lock/subsys/<service-name> file
when started/stopped. Check out how sshd and xinetd works.

To make all of this work, you may need to change a few file ownerships
to "root" from "SYSTEM" (mainly ssh files in /etc), and change a few
"user = SYSTEM" into "user = root" in xinetd's config files. That is a
bit of a hassle, but it's quite easy to locate troublespots when you can
"Run as" rxvt as root and just test the start scripts directly (as
opposed to running a service and pray that it works...).

But now it works (almost) perfectly, running apache, cron, sshd, xinetd,
ipc-daemon and postmaster. The only problem I've seen is that cron
restarts itself as SYSTEM, even when started as root, for some reason.

/dan

--
Dan Holmsand
IB
dan(at)eyebee(dot)com

Dan,

On Fri, Jan 24, 2003 at 07:22:48PM +0100, Dan Holmsand wrote:
> Jason Tishler wrote:
> >BTW, by "sysv start script" do you mean using the sysvinit package.
> >If so, then how did you get around the following issues:
> >
> > http://www.cygwin.com/ml/cygwin/2002-11/msg00669.html
> > http://www.cygwin.com/ml/cygwin/2002-11/msg00677.html
> > http://www.cygwin.com/ml/cygwin/2002-11/msg00838.html
>
> Yeah, sysvinit and initscripts. I've been hoping something like that
> would show up in cygwin for quite some time, so I've struggled a bit
> to make it work.
>
> [snip]
>
> But then I noticed that su actually *does* work if a privileged enough
> user with uid 0 (i.e. "root") runs it. [snip]
>
> But now it works (almost) perfectly, running apache, cron, sshd,
> xinetd, ipc-daemon and postmaster. The only problem I've seen is that
> cron restarts itself as SYSTEM, even when started as root, for some
> reason.

Thanks for the above description. However, creating another privileged
user, root, in addition to LocalSystem is unnecessary and dangerous.
Instead, I would use my patch to su (the first URL above) so su will run
under LocalSystem on Cygwin the same way it would under root on other
Unixes. With this patched su, you can then run init under LocalSystem
as recommended.

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason,

Jason Tishler wrote:
> Thanks for the above description. However, creating another privileged
> user, root, in addition to LocalSystem is unnecessary and dangerous.
> Instead, I would use my patch to su (the first URL above) so su will run
> under LocalSystem on Cygwin the same way it would under root on other
> Unixes. With this patched su, you can then run init under LocalSystem
> as recommended.

I see your point, but I don't agree :-)

There are some (important, IMHO) advantages to run init as uid 0 (a.k.a.
root), instead of as LocalSystem:

1) You can log on as root. More importantly, you can use W2K's "Run as"
utility to run e.g. rxvt as root, and execute init scripts interactively
(as in "/etc/rc.d/init.d/sshd restart").

That makes life a *lot* easier when debugging, temporarily disabling
services, etc. Executing typical sysv init scripts as another user, e.g.
"Administrator", will result in failure or disaster (depending on script
and privileges).

2) You can use su when running as root. Also makes life a lot easier:
just say "su postgres -c 'psql template1'" to administer postgresql.

3) You probably *gain* some security. Many (most?) unix daemons behave
differently when run as uid 0, in order to prevent certain exploits or
configuration errors when running as root. Just one example: apache
(wisely) refuses to run with "User root" in httpd.conf, but happily
accepts "User system".

Unless such programs are really, really carefully ported to Cygwin, you
get a security hole when running them as uid 18 (i.e. "SYSTEM").

4) It just feels a bit more unixy :-)

Just my $0.02.

/dan

Dan,

On Mon, Jan 27, 2003 at 10:10:55PM +0100, Dan Holmsand wrote:
> There are some (important, IMHO) advantages to run init as uid 0
> (a.k.a. root), instead of as LocalSystem:

Not really, see below...

> 1) You can log on as root. More importantly, you can use W2K's "Run
> as" utility to run e.g. rxvt as root, and execute init scripts
> interactively (as in "/etc/rc.d/init.d/sshd restart").

You *can* log on as LocalSystem via ssh:

1. Replace the following /etc/passwd line:

SYSTEM:*:18:544:,S-1-5-18::

with something like:

SYSTEM:*:18:18:Local System,U-TISHLERJASON\LocalSystem,S-1-5-18:/home/system:/bin/bash

2. Add your keys to ~system/.ssh/authorized_keys

3. ssh system(at)localhost

There is also cmdasuser:

http://www.develop.com/kbrown/security/sample_cmdasuser.htm

which can switch user to LocalSystem too.

> That makes life a *lot* easier when debugging, temporarily disabling
> services, etc. Executing typical sysv init scripts as another user,
> e.g. "Administrator", will result in failure or disaster (depending
> on script and privileges).

See above.

> 2) You can use su when running as root. Also makes life a lot easier:
> just say "su postgres -c 'psql template1'" to administer postgresql.

Ditto.

> 3) You probably *gain* some security. Many (most?) unix daemons behave
> differently when run as uid 0, in order to prevent certain exploits or
> configuration errors when running as root. Just one example: apache
> (wisely) refuses to run with "User root" in httpd.conf, but happily
> accepts "User system".
>
> Unless such programs are really, really carefully ported to Cygwin,
> you get a security hole when running them as uid 18 (i.e. "SYSTEM").

Then those ports (e.g., apache) are broken and should be fixed. For
example, my fetchmail, procmail, and vsftpd ports recognized uid 18 as
the root uid and behave accordingly.

> 4) It just feels a bit more unixy :-)

I guess so, but when in Rome... :,)

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6

Jason,

Really sorry to be stubborn, but I happen to think that this is an
interesting subject...

Jason Tishler wrote:
> You *can* log on as LocalSystem via ssh:

I know. The disadvantage is of course that anyone that can run as me
also gets access to LocalSystem without any password checks at all.

> There is also cmdasuser:
>
> http://www.develop.com/kbrown/security/sample_cmdasuser.htm
>
> which can switch user to LocalSystem too.

Wow. That's scary! That actually shows that running as a member of
Administrators is pretty much exactly as dangerous as running with
"Create a token object" etc. privilegies, since they obviously can be so
easily acquired.

Anyway, cmdasuser doesn't work very conveniently for me: I'm not a
member of "Administrators" (for security reasons). Even if I was, it
feels like a pretty big security risk just to have that kind of thing
laying around :-). And it doesn't work remotely. Also, it has a nasty
habit of killing child processes on exit, so "/etc/rc.d/init.d/sshd
restart" is a small disaster...

>>Unless such programs are really, really carefully ported to Cygwin,
>>you get a security hole when running them as uid 18 (i.e. "SYSTEM").
>
>
> Then those ports (e.g., apache) are broken and should be fixed. For
> example, my fetchmail, procmail, and vsftpd ports recognized uid 18 as
> the root uid and behave accordingly.

Now that's a really good argument. In particular, my running as uid 0
breaks "correctly ported" apps in this regard. OTOH, I maintain that
getting this 100% right is non-trivial, since it is quite untestable.

If Cygwin's intention is that uid 18 should be equivalent to Unix' uid
0, then why on earth is Local System uid 18?

>>4) It just feels a bit more unixy :-)
>
>
> I guess so, but when in Rome... :,)

Hmm. I always thought the whole purpose of Cygwin was to save me from
the evils of Rome (or Redmond, to be a bit more precise). ;-)

/dan

Dan,

On Tue, Jan 28, 2003 at 01:00:11AM +0100, Dan Holmsand wrote:
> Really sorry to be stubborn,

No problem.

> but I happen to think that this is an interesting subject...

Agreed, but maybe we should move this thread to the Cygwin list?

> Jason Tishler wrote:
> >You *can* log on as LocalSystem via ssh:
>
> I know. The disadvantage is of course that anyone that can run as me
> also gets access to LocalSystem without any password checks at all.

Agreed, but someone can attack your root account too.

> >There is also cmdasuser:
> >
> > http://www.develop.com/kbrown/security/sample_cmdasuser.htm
> >
> >which can switch user to LocalSystem too.
>
> Wow. That's scary! That actually shows that running as a member of
> Administrators is pretty much exactly as dangerous as running with
> "Create a token object" etc. privilegies, since they obviously can be
> so easily acquired.

Yup!

> Anyway, cmdasuser doesn't work very conveniently for me: I'm not a
> member of "Administrators" (for security reasons). Even if I was, it
> feels like a pretty big security risk just to have that kind of thing
> laying around :-).

Agreed!

> And it doesn't work remotely. Also, it has a nasty habit of killing
> child processes on exit, so "/etc/rc.d/init.d/sshd restart" is a small
> disaster...

I just threw out cmdasuser to demonstrate that there was YA way to
become the LocalSystem user.

> >>Unless such programs are really, really carefully ported to Cygwin,
> >>you get a security hole when running them as uid 18 (i.e. "SYSTEM").
> >
> >Then those ports (e.g., apache) are broken and should be fixed. For
> >example, my fetchmail, procmail, and vsftpd ports recognized uid 18 as
> >the root uid and behave accordingly.
>
> Now that's a really good argument. In particular, my running as uid 0
> breaks "correctly ported" apps in this regard. OTOH, I maintain that
> getting this 100% right is non-trivial, since it is quite untestable.

Why is it untestable? Plus, the source for all Cygwin apps are
available for inspection.

> If Cygwin's intention is that uid 18 should be equivalent to Unix' uid
> 0, then why on earth is Local System uid 18?

It was a regrettable choice by Corinna. :,) Actually, Cygwin UIDs are
derived from the last component of the user's SID. For example:

SYSTEM:*:18:544:,S-1-5-18::
^^ ^^

> >>4) It just feels a bit more unixy :-)
> >
> >I guess so, but when in Rome... :,)
>
> Hmm. I always thought the whole purpose of Cygwin was to save me from
> the evils of Rome (or Redmond, to be a bit more precise). ;-)

Touche!

Jason

--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6