This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: rsh: "Permission denied" on file creation. Cygwin 1.3.3 on W2K Adv Srv SP2.


OK. Now, from what I've gathered, there seems to be some dispute as to what
SYSTEM can do. But, since I can write to an existing file with an rsh
invocation, it would seem that enough privileges are set in this case.
 
>Or, much easier, the process running under System account activates 
>its SeRestorePrivilege and reads the file or activates its 
>SeBackupPrivilege and writes the file using FILE_FLAG_BACKUP_SEMANTICS. 
>System has both rights set by default.  They are just not activated 
>by default as it's given for most dangerous privileges in NT. 

Is it then a bug/oversight that rsh cannot create a file, or is it intended
(cryptic) behavior ? I will be happy to reproduce the problem on a Win2K
server starting from scratch, supplying debug info if someone can point me
in the right direction as to how.

-- Jan Holst Jensen

-----Original Message-----
From: Robert Collins
To: John Peacock; Corinna Vinschen
Sent: 10/14/01 4:09 PM
Subject: Re: rsh: "Permission denied" on file creation. Cygwin 1.3.3 on W2K
Adv  Srv SP2.

----- Original Message -----
From: "John Peacock" <jpeacock@rowman.com>
To: "Corinna Vinschen" <cygwin@cygwin.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/

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]