Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3BCB0C7D.148867EF@cportcorp.com>
Date: Mon, 15 Oct 2001 12:19:09 -0400
From: Peter Buckley <peter DOT buckley AT cportcorp DOT com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: John Peacock <jpeacock AT rowman DOT com>, Corinna Vinschen <cygwin AT cygwin DOT com>
Subject: Re: rsh: "Permission denied" on file creation. Cygwin 1.3.3 on W2K Adv  
 Srv SP2.
References: <FF503547C1F8D211BD2C0008C7C564010C9A492A AT exdkba06 DOT novo DOT dk> <3BC72151 DOT F11E6CB0 AT cportcorp DOT com> <20011013105919 DOT O1155 AT cygbert DOT vinschen DOT de> <3BC89445 DOT DEED628 AT rowman DOT com> <007d01c154b9$d088be30$0200a8c0 AT lifelesswks>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ummm.... I don't understand why home directories on 
a network share would ever be "public". I thought that 
root on unix could read whatever it wanted 
(including home directories on network shares, 
hence SYSTEM is NOT equivalent), but this 
idea of public sounds like anyone (the guest user) or 
some intruder could read the contents of my home 
directory on a network share without authenticating. 
That just sounds silly, so maybe I need someone to 
explain this idea of "public" to me. 

Basically, the problem here is the "security" feature 
that rsh uses where it tries to cd to the user's home 
directory as the SYSTEM account, then failing that 
exits if CYGWIN is defined. This is ridiculous. 
When I rsh, the whole idea is that I am "me" and I am 
executing commands as "me" on the remote system. I don't 
want to cd to my home directory as SYSTEM, and in this 
case it doesn't work because it is a network share and 
kicks me out. 

I know that I can modify the code so it doesn't do this, 
but I don't think it should use this security feature this 
way. There are probably a bunch of NT users who have their 
home directories on network shares. It was explained to me 
that the whole idea of this security feature is so an 
unauthorized user doesn't end up in the / directory. The 
section of code does this-

if (cd $HOME)
#okay, we cd'd to the home directory no problem
else
ifdef _CYGWIN_
error (no remote directory; exit1)
else
cd /
endif
endif

Why can't the "cd /" simply be a "cd /some-harmless-place" 
and provide the same level of security? Simply saying 
"you shouldn't have your home directory on a network share" 
isn't good enough. Maybe I just don't understand the idea 
of making my home directory "public" and if someone explains 
it to me I can tell my sysadmins and have them set it up that 
way.

TIA,
Peter
Robert Collins wrote:
> 
> ----- Original Message -----
> From: "John Peacock" <jpeacock AT rowman DOT com>
> To: "Corinna Vinschen" <cygwin AT cygwin DOT com>
> Sent: Sunday, October 14, 2001 5:21 AM
> Subject: Re: rsh: "Permission denied" on file creation. Cygwin 1.3.3 on
> W2K Adv Srv SP2.
> 
> > Some of this may be caused by what I said in another e-mail.  Let
> > me write out what my understanding of the SYSTEM account and you
> > can correct me.
> >
> > 1) NT services need to have access to certain internal security
> > attributes, such as "Act as Part of Operating system", "Create
> > a token object" and "Replace a Token object."  System has these
> > rights and more and is intended to be used for local NT services.
> 
> (Caveat: NT is quite flexible in design, I'm not sure that MS's default
> services will work correctly if you change the privileges given to the
> SYSTEM account...)
> 
> One of the headaches older NT versions have is that System *does* have
> access to everything by default. And IIRC it is not possible under NT 4
> and below to remove any of the privileges from the SYSTEM account.
> Services running under System are therefore equivalent to daemons
> running as root in unix. NT Services *DO NOT in general* need the
> privileges you list above to operate. To perform specific tasks some
> services do need such rights it's true, just not the general case (and
> you are making a general statement).
> 
> > 2) SYSTEM does not have rights to any other machine; it is strictly
> > a local account.  This means that it cannot use drive shares (even
> > if they are public shares).
> 
> SYSTEM is quite capable of running a network sniffing password cracker!.
> SYSTEM however cannot use the *integrated* authentication functions
> (GSSAPI IIRC) to present credentials to another server. So local is a
> rather relative term.
> 
> > 3) SYSTEM does not have rights, by itself, to any files on the local
> > machine that are not public.  In other words, files owned by a
> > specific user are not accessable to SYSTEM.  However, an NT service
> > run under the SYSTEM account can impersonate any other local user
> > account, if written that way, so the SYSTEM account can access local
> > files in that fashion.
> 
> Not true, the default rights for NT on newly formatted partition are
> Everyone:F. System is included there. If you deliberately setup an ACL
> with SYSTEM not included, or SYSTEM denied, then a process running as
> SYSTEM would have to use one of it's privileges as described by Corinna.
> 
> > Consequently, although SYSTEM is the usual account that is used by
> > NT to run services, it is not strictly equivalent to root under *nix,
> 
> Sorry, it *is* strictly equivalent to root. It can do everything. Unlike
> most *nix, NT has 'capabilities', and SYSTEM has the ability to turn on
> more access than it gets be default - see Corinna's message. I suspect
> that managing a capability based *nix, or a Mandatory Access Control
> environment will be very similar to securing an NT machine to the hilt..
> 
> > Some Cygwin programs that can be run as services under NT will not
> > work properly under SYSTEM, since they have not been written to
> > impersonate users.
> 
> I don't see that: Impersonating a user is not a requirement per se of
> being a service. For any program that has an interprocess comms path, be
> it a unix socket, a fifo, or shared memory, it is designed to run as a
> different user than the calling user. If it doesn't have such a comms
> path, how can it run as a daemon at all?
> 
> Rob
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

-- 
Your mouse has moved.
Windows NT must be restarted for the change to take effect.
Reboot now?  [OK]

--

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/