This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: rsh: "Permission denied" on file creation. Cygwin 1.3.3 on W2K Adv Srv SP2.
On Sat, Oct 13, 2001 at 03:21:41PM -0400, John Peacock wrote:
> Corinna Vinschen wrote:
> >
> > Ouch! Where did you get that information? SYSTEM is exactly
> > _the_ privileged user account which has all rights neccessary
> > for an operating system. It's the real "root" account for NT
> > in contrast to the Administrators which are not allowed to do
> > everything (e.g. user context switches).
> >
> > The only restriction SYSTEM suffers from is, it has no access
> > to network shares which require authentication... which makes
> > sense.
>
> 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.
System has these rights but it's not the intend for system to
run services in the first place. Look into XP where you'll find
two new builtin accounts `Local Service' (S-1-5-19) and
`Network Service' (S-1-5-20) which are explicitely designed to
start services with specific rights. The reason that many
services are started as System is the same as many daemons under
Unix are started as root - the service/daemon designer knows
or thinks to know that special privileges are needed for the
application.
> 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).
Wrong. If a share of another machine is explicitely `public',
System accounts can access these shares. This is pretty different
from shares which are accessible by all authenticated users! An
authenticated user needs an authentication as the name already says.
A public share is one which doesn't require any authentication as,
e.g. the following "/tmp" path on a U*X box running Samba. From
an smb.conf file:
[tmp]
comment = Temporary file space
path = /tmp
public = yes
create mask = 0777
> 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.
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.
> Consequently, although SYSTEM is the usual account that is used by
> NT to run services, it is not strictly equivalent to root under *nix,
> since it does not have rights to everything. However, through the
> use of user impersonation, SYSTEM can act as any user and is in that
> way very similar to "su username" under *nix.
That's not correct. System is the account which has _all_ NT
privileges. In that regard it _is_ like a root account under
U*X. In contrast to U*X systems NT users don't have all of these
privileges activated on application start. This is a security
issue and doesn't mean that System isn't as powerful as a root.
And as far as shares are concerned... isn't that restricted access
to shares comparable to the restriction of root permissions on
NFS shares (root sqashing)?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin@cygwin.com
Red Hat, Inc.
--
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/