[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ownership Issues Running as pserver vs. server

From: Mark D. Baushke
Subject: Re: Ownership Issues Running as pserver vs. server
Date: Sun, 31 Oct 2004 07:38:34 -0800

Hash: SHA1

Malhotra, Neti <address@hidden> writes:
> I am looking for an opinion on the correct way to configure my server
> so that I can access CVS locally from the server as well as from a PC
> using WinCVS. Here's the dilemna.
> Before upgrading to cvs 1.11.17, cvs was owned by a user on our system
> called cvs (id=9001), and group also called cvs (id=2525) with the
> sticky bit set (i.e. 4755). Therefore most of the files in the
> repository are owned by 9001:2525. With 1.11.17 configured as before,
> running cvs locally works, but running in pserver mode fails. I think
> what is happening in pserver mode is:
> - Inetd kicks off cvs as root:root, so the relevant ids are:
>       real user is root:root
>             user is retrieved from password file as root:other
>             effective user is 9001:root
> - Cvs tries to setgid to the group id retrieved from the password file 
> (other).  I'm guessing this fails because the effective user is 9001.
> I tried to fix this by unsetting the sticky bit on the cvs executable,
> i.e. keep it owned by 9001:2525 and keep perms at 755. That worked
> just fine in pserver mode, but now causes cvs to fail (unable to
> create cvslock) when running it on the server.
> I decided then to change the ownership of cvs to root:2525, with the
> sticky bit set (perms=4755). This seems to work for both pserver and
> server modes, but now the files in the repository are owned by root. I
> don't know that this is necessarily a bad thing, but it makes me a
> little nervous.
> Does anyone have any suggestions/opinions on the correct way to set
> this up? I guess another option may be to kick off cvs as the 9001
> user in inetd. Do you think that's a better option?

Hi Neti,

You will probably want to build your cvs executable with

passed to the compiler for the files filesubr.c, run.c and server.c

If I had to guess, that is actually how any previous version of cvs had
to be compiled for things to have worked for you in the past.

Note that defining SETXID_SUPPORT is NOT a well tested option.

        Good luck,
        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]