Thread: Initdb fails... Again!
Hello! I have successfully installed PostgreSQL with Cygwin as a service on Windows XP prof. and Windows2000 prof. Now I try to repeat the procedure more on another Windows2000server. After installing ipc-daemon (1.13-2) as a service and starting it, initdb still fails! I also tried to run ipc-daemon in normal mode (ipc-daemon &), but still, it seems that initdb cannot connect to it or something.... What may be wrong? postgres@PULL ~ $ initdb -D /usr/share/postgresql/data The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. creating directory /usr/share/postgresql/data... ok creating directory /usr/share/postgresql/data/base... ok creating directory /usr/share/postgresql/data/global... ok creating directory /usr/share/postgresql/data/pg_xlog... ok creating directory /usr/share/postgresql/data/pg_clog... ok creating template1 database in /usr/share/postgresql/data/base/1... IpcSemaphore Create: semget(key=1, num=17, 03600) failed: Function not implemented initdb failed. Removing /usr/share/postgresql/data. postgres@PULL ~ Regards, Markko Paas markko@softronic.ee
Markko,
On Thu, Jan 16, 2003 at 10:16:23PM +0200, Markko Paas wrote:
> Now I try to repeat the procedure more on another Windows2000server.
>
> After installing ipc-daemon (1.13-2) as a service and starting it,
> initdb still fails! I also tried to run ipc-daemon in normal mode
> (ipc-daemon &), but still, it seems that initdb cannot connect to it
> or something.... What may be wrong?
Are you running the latest PostgreSQL, 7.3.1-1, on this machine? Older
versions may not work with the latest cygipc, 1.13-2.
What happens when you run ipctest when ipc-daemon is running?
$ ipctest s
Test v0.03
semaphore 0 created
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
Thank you for quick feedback!
Ipc-daemon is running as a service - an excerpt from ps -a -W
----
3588 1 3588 3588 con 1051 22:02:56 /usr/bin/bash
3488 0 0 3488 ? 0 22:03:17
C:\cygwin\usr\local\bin\ipc-daemon.exe
3828 0 0 3828 ? 0 07:48:10
C:\WINNT\System32\svchost.exe
3836 0 0 3836 ? 0 08:24:08
C:\WINNT\system32\mmc.exe
----
PostgreSQL version is 7.3.1-1
But ipctest fails!
----
postgres@PULL ~
$ ipctest s
Test v0.03
Unable to create semaphore
semget : Function not implemented
----
-----Original Message-----
From: Jason Tishler [mailto:jason@tishler.net]
Sent: 16. jaanuar 2003. a. 23:00
To: Markko Paas
Cc: pgsql-cygwin@postgresql.org
Subject: Re: [CYGWIN] Initdb fails... Again!
Markko,
On Thu, Jan 16, 2003 at 10:16:23PM +0200, Markko Paas wrote:
> Now I try to repeat the procedure more on another Windows2000server.
>
> After installing ipc-daemon (1.13-2) as a service and starting it,
> initdb still fails! I also tried to run ipc-daemon in normal mode
> (ipc-daemon &), but still, it seems that initdb cannot connect to it
> or something.... What may be wrong?
Are you running the latest PostgreSQL, 7.3.1-1, on this machine? Older
versions may not work with the latest cygipc, 1.13-2.
What happens when you run ipctest when ipc-daemon is running?
$ ipctest s
Test v0.03
semaphore 0 created
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 Fri, Jan 17, 2003 at 09:03:20AM +0200, Markko Paas wrote:
> Thank you for quick feedback!
You are welcome.
> Ipc-daemon is running as a service - an excerpt from ps -a -W
Good.
> PostgreSQL version is 7.3.1-1
Good.
> But ipctest fails!
Bad. If ipctest fails, then so will PostgreSQL. :,(
> $ ipctest s
> Test v0.03
> Unable to create semaphore
> semget : Function not implemented
My WAG is a permissions problem. What do you get when you run the
following?
$ ls -ld /tmp /tmp/cygipc_* /tmp/MultiFile*
drwxrwxrwx+ 101 Administ None 176128 Jan 17 10:56 /tmp
-rw-rw-rw- 1 SYSTEM SYSTEM 3916520 Jan 13 15:32 /tmp/MultiFileMsg
-rw-rw-rw- 1 SYSTEM SYSTEM 22032 Jan 13 15:32 /tmp/MultiFileSem
-rw-rw-rw- 1 SYSTEM SYSTEM 202768 Jan 13 15:32 /tmp/MultiFileShm
-rw------- 1 jt None 1441792 Jan 13 16:30 /tmp/cygipc_0
If /tmp is less than 777, then make it so and delete /tmp/MultiFile*.
Does this help?
BTW, are you running ipc-daemon with "--tight-security"? If so, then do
not run with this option because it seems to prevent IPC from working
across different user accounts:
$ id
uid=18(SYSTEM) gid=18(SYSTEM) groups=544(Administrators)
$ ipc-daemon --tight-security &
$ ipctest s
Test v0.03
semaphore 0 created
$ id
uid=1000(jt) gid=513(None) groups=513(None),544(Administrators),...
$ ipctest s
Test v0.03
Unable to create semaphore
semget : Function not implemented
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,
Please keep your replies on-list.
On Mon, Jan 20, 2003 at 09:01:38AM +0200, Markko Paas wrote:
> $ ls -ld /tmp /tmp/cygipc_* /tmp/MultiFile*
> ls: /tmp/cygipc_*: No such file or directory
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The above is bad.
What do you get when run the following:
$ ls -ld /tmp/cygipc*
> The problem seems to be that there is no cygipc_* file!!!
> I checked - the CygIPC service is still running nicely.
Are you sure that you are really running 1.13-2?
$ ipc-daemon --version
ipc-daemon : Cygwin IPC Package Version 1.13 (c) 1998 PCH/LLA, ...
cygipc renamed /tmp/cygipc0 to /tmp/cygipc_0 between version 1.11 and
1.13. Please make sure that you are running the latest version.
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
Strange things happen here.... > Please keep your replies on-list. > > On Mon, Jan 20, 2003 at 09:01:38AM +0200, Markko Paas wrote: > > $ ls -ld /tmp /tmp/cygipc_* /tmp/MultiFile* > > ls: /tmp/cygipc_*: No such file or directory > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > The above is bad. > > What do you get when run the following: > > $ ls -ld /tmp/cygipc* There are only MultiFile's in the /tmp directory, no other files > > > The problem seems to be that there is no cygipc_* file!!! > > I checked - the CygIPC service is still running nicely. > > Are you sure that you are really running 1.13-2? > > $ ipc-daemon --version > ipc-daemon : Cygwin IPC Package Version 1.13 (c) 1998 PCH/LLA, ... Now, here comes a strange part.... Neither ipc-daemon --version or ipc-daemon --help didn't give any output!! It seems that ipc-daemon doesn't want to run at all!!! But the process is running. I think I installed the CygIPC correctly, downloaded 1.13-2, then unpacked and copied the files into subdirectories under c:/cygwin/ How hard can it be? Is there any possible piece that can conflict with ipc-daemon in a previously mentioned way??? Markko
Markko,
On Mon, Jan 20, 2003 at 05:38:28PM +0200, Markko Paas wrote:
> Strange things happen here....
Yes and no.
> There are only MultiFile's in the /tmp directory, no other files
Again, this is very bad.
> Now, here comes a strange part....
Unfortunately, ipc-daemon will *not* output correctly in a bash or cmd
window. Do you have rxvt installed? If so, then try again in an rxvt
window. Otherwise, do the following in a cmd window:
C:\> ipc-daemon --version 2>ipc-ver.txt
C:\> cat ipc-ver.txt
ipc-daemon : Cygwin IPC Package Version 1.13 (c) 1998 PCH/LLA, ...
> I think I installed the CygIPC correctly, downloaded 1.13-2, then
> unpacked and copied the files into subdirectories under c:/cygwin/
Did you ever have a previous cygipc version installed? If the old
version was running when you installed the new one, the new ipc-daemon
would not have been installed.
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
> > Now, here comes a strange part....
>
> Unfortunately, ipc-daemon will *not* output correctly in a
> bash or cmd window. Do you have rxvt installed? If so, then
> try again in an rxvt window. Otherwise, do the following in
> a cmd window:
>
> C:\> ipc-daemon --version 2>ipc-ver.txt
> C:\> cat ipc-ver.txt
> ipc-daemon : Cygwin IPC Package Version 1.13 (c) 1998 PCH/LLA, ...
>
Here's mine:
$ cat ipc-ver.txt
6 [unknown (0xED4)] ipc-daemon 3820
fhandler_console::fixup_after_exec: er
ror opening input console handle after exec, errno 13, Win32 error 5
12547 [unknown (0xED4)] ipc-daemon 3820
fhandler_console::fixup_after_exec: er
ror opening input console handle after exec, errno 13, Win32 error 5
21031 [unknown (0xED4)] ipc-daemon 3820
fhandler_console::fixup_after_exec: er
ror opening input console handle after exec, errno 13, Win32 error 5
29062 [unknown (0xED4)] ipc-daemon 3820
fhandler_console::fixup_after_exec: er
ror opening input console handle after exec, errno 13, Win32 error 5
ipc-daemon : Cygwin IPC Package Version 1.13 (c) 1998 PCH/LLA, Changes
(c) 2001
CSW
This daemon provides InterProcess Communication services for Cygwin.
Isnt that interesting??? :-)
> > I think I installed the CygIPC correctly, downloaded 1.13-2, then
> > unpacked and copied the files into subdirectories under c:/cygwin/
>
> Did you ever have a previous cygipc version installed? If
> the old version was running when you installed the new one,
> the new ipc-daemon would not have been installed.
No, I have used the latest one only.
Markko
Markko,
On Mon, Jan 20, 2003 at 06:30:32PM +0200, Markko Paas wrote:
> $ cat ipc-ver.txt
> 6 [unknown (0xED4)] ipc-daemon 3820
> fhandler_console::fixup_after_exec: error opening input console handle after exec, errno 13, Win32 error 5
> ipc-daemon : Cygwin IPC Package Version 1.13 (c) 1998 PCH/LLA, Changes (c) 2001 CSW
>
> Isnt that interesting??? :-)
Yes. What is your Cygwin version?
$ uname -a
CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030119 22:03:54 i686 unknown
Please upgrade to the latest snapshot:
http://cygwin.com/snapshots/
and try again.
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
Well, I copied the snapshot.
But I had a bit different directory tree ... I don't think that can
cause any problem, but...
I copied
/usr/bin, /usr/etc, /usr/lib --> /cygwin
/usr/include, /usr/info /usr/man --> /cygwin/usr (as it should be??)
Still the same result:
$ uname -a
CYGWIN_NT-5.0 pull 1.3.19s(0.71/3/2) 20030119 22:03:54 i686 unknown
unknown Cygw
in
postgres@pull ~
$ rm ipc-ver.txt
postgres@pull ~
$ ipc-daemon --version 2>ipc-ver.txt
postgres@pull ~
$ cat ipc-ver.txt
6 [unknown (0xF58)] ipc-daemon 3700
fhandler_console::fixup_after_exec: er
ror opening input console handle after exec, errno 13, Win32 error 5
21567 [unknown (0xF58)] ipc-daemon 3700
fhandler_console::fixup_after_exec: er
ror opening input console handle after exec, errno 13, Win32 error 5
30341 [unknown (0xF58)] ipc-daemon 3700
fhandler_console::fixup_after_exec: er
ror opening input console handle after exec, errno 13, Win32 error 5
38226 [unknown (0xF58)] ipc-daemon 3700
fhandler_console::fixup_after_exec: er
ror opening input console handle after exec, errno 13, Win32 error 5
ipc-daemon : Cygwin IPC Package Version 1.13 (c) 1998 PCH/LLA, Changes
(c) 2001
CSW
This daemon provides InterProcess Communication services for Cygwin.
> -----Original Message-----
> From: Jason Tishler [mailto:jason@tishler.net]
> Sent: 20. jaanuar 2003. a. 18:52
> To: Markko Paas
> Cc: pgsql-cygwin@postgresql.org
> Subject: Re: [CYGWIN] Initdb fails... Again!
>
>
> Markko,
>
> On Mon, Jan 20, 2003 at 06:30:32PM +0200, Markko Paas wrote:
> > $ cat ipc-ver.txt
> > 6 [unknown (0xED4)] ipc-daemon 3820
> > fhandler_console::fixup_after_exec: error opening input
> console handle
> > after exec, errno 13, Win32 error 5 ipc-daemon : Cygwin IPC Package
> > Version 1.13 (c) 1998 PCH/LLA, Changes (c) 2001 CSW
> >
> > Isnt that interesting??? :-)
>
> Yes. What is your Cygwin version?
>
> $ uname -a
> CYGWIN_NT-5.0 TISHLERJASON 1.3.19s(0.71/3/2) 20030119
> 22:03:54 i686 unknown
>
> Please upgrade to the latest snapshot:
>
http://cygwin.com/snapshots/
and try again.
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 Mon, Jan 20, 2003 at 07:35:37PM +0200, Markko Paas wrote: > Well, I copied the snapshot. > But I had a bit different directory tree ... I don't think that can > cause any problem, but... > I copied > /usr/bin, /usr/etc, /usr/lib --> /cygwin > /usr/include, /usr/info /usr/man --> /cygwin/usr (as it should be??) Sorry, but I guess that I should have been more clear. I meant just replace your cygwin1.dll with the latest snapshot -- not the entire binary tree. > Still the same result: > > $ uname -a > CYGWIN_NT-5.0 pull 1.3.19s(0.71/3/2) 20030119 22:03:54 i686 unknown > > postgres@pull ~ > $ rm ipc-ver.txt > > postgres@pull ~ > $ ipc-daemon --version 2>ipc-ver.txt > > postgres@pull ~ > $ cat ipc-ver.txt > 6 [unknown (0xF58)] ipc-daemon 3700 > fhandler_console::fixup_after_exec: er > ror opening input console handle after exec, errno 13, Win32 error 5 Please take this problem to the Cygwin list <cygwin@cygwin.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
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@cygwin.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
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
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
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@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
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
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
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
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
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@eyebee.com