ruas in the same console


S

sali

is it posible to run "runas" command *without* having started the new cmd
instance, i mean, in the same console window, inheriting previous cmd
history and env vars? something like "su" command in unix/linux

thnx!
 
Ad

Advertisements

D

David Trimboli

is it posible to run "runas" command*without* having started the new cmd
instance, i mean, in the same console window, inheriting previous cmd
history and env vars? something like "su" command in unix/linux
Nope. Windows can only run under a single user context at a time. The
shell itself doesn't understand user contexts, only the window manager.
 
S

sali

David Trimboli said:
Nope. Windows can only run under a single user context at a time. The
shell itself doesn't understand user contexts, only the window manager.

thnx for the explanation
my question was for the win/xp, but is it the same behaviour even for the
newest win/7?

i saw that the newer wins are more and more unix-like.
on my win/vista laptop, i even found the old fashioned telnet-server!
 
J

Jonathan de Boyne Pollard

is it posible to run runas command without having started the new cmd instance, i mean, in the same console window, inheriting previous cmd history and env vars? something like su command in unix/linux



Nope. Windows can only run under a single user context at a time. The shell itself doesn't understand user contexts, only the window manager.



All three sentences there are wrong.  Let's start with "Nope.".  It is possible.  In theory a utility could be written to obtain the necessary process token and invoke a new child process, inheriting the utility program's environment and console, using that token.  And in practice, MKS seems to have written exactly such a utility.




Windows most definitely can run under multiple user contexts at the same time.  That is, after all, what enables Fast User Switching, for starters.  This isn't just an attribute of FUS, though.  The ability to have multiple processes associated with multiple users has been in Windows NT ab initio, and it has been used ab initio, too.  Multiple processes with multiple user accounts is part of what prevents, say, an unprivileged account mucking around with the internals of the LSA server process.




The "Window manager" (which for the sake of exposition I'll assume is a vague reference to a combination of the CSRSS process, the WIN32K driver, and the DWM) really isn't involved in multiple user contexts.  The "Window manager" actually deals in desktops, window stations, and sessions.  The relationship between each of all three of those and user accounts is not necessarily one-to-one.  Desktops can have multiple processes with multiple user accounts accessing them.  That is what shatter attacks are all about.  Window stations can have multiple processes with multiple user accounts.  Fast User Switching switches a single window station amongest multiple users, after all.  And sessions are not login sessions.
 
T

Tim Meddick

Although what "David Trimboli" says is completely true, however, it is possible to
use the environment belonging to the cmd window that executed "runas", rather than
initializing the user's environment set belonging to the target user of the "runas"
command.

This is done with the [/env] switch.

Type : [ runas /? ] for help.

For more help, look up RUNAS in the Window's Help and Support Centre.

==

Cheers, Tim Meddick, Peckham, London. :)
 
D

David Trimboli

All three sentences there are wrong. Let's start with "Nope.". It is
possible. In theory a utility could be written to obtain the necessary
process token and invoke a new child process, inheriting the utility
program's environment and console, using that token. And in practice,
MKS seems to have written exactly such a utility
<http://mkssoftware.com./docs/man1/su.1.asp>.
Yes, if you write a custom shell that uses a console-style window, you
could write it to include access to multiple user contexts. But the
original question asked about instances of cmd, not other shells.
Windows most definitely /can/ run under multiple user contexts at the
same time. That is, after all, what enables Fast User Switching, for
starters.
Nonono, if that word hadn't been the first word of a sentence, it would
have been lowercase. Not "Windows operating system," but "instance of a
window on the screen."
The "Window manager" (which for the sake of exposition I'll assume is a
vague reference to a combination of the CSRSS process, the WIN32K
driver, and the DWM) really isn't involved in multiple user contexts.
Let me rephrase. "The CMD shell doesn't deal with user contexts, so the
window in which it runs is always assumed to be of a single context."

The original poster wanted to know if you could force an instance of CMD
to jump to a different user context, or a different instance of CMD
under a different user context, in the same window. You can't.
 
Ad

Advertisements

D

David Trimboli

Right. This will still generate a new console window, but the variables
and history and so on from the old window will be carried over.

Although what "David Trimboli" says is completely true, however, it is
possible to use the environment belonging to the cmd window that
executed "runas", rather than initializing the user's environment set
belonging to the target user of the "runas" command.

This is done with the [/env] switch.

Type : [ runas /? ] for help.

For more help, look up RUNAS in the Window's Help and Support Centre.

==

Cheers, Tim Meddick, Peckham, London. :)




sali said:
is it posible to run "runas" command *without* having started the new
cmd instance, i mean, in the same console window, inheriting previous
cmd history and env vars? something like "su" command in unix/linux

thnx!
 
D

David Trimboli

thnx for the explanation
my question was for the win/xp, but is it the same behaviour even for the
newest win/7?

i saw that the newer wins are more and more unix-like.
on my win/vista laptop, i even found the old fashioned telnet-server!
The behavior of CMD in Windows 7 has not changed. (Though console
windows can no longer be made full-screen as of Windows Vista.)
 
A

Al Dunbar

Similarly with windows appearing in different security context one can, for
example, cut and paste between, but not necessarily drag and drop.

/Al

David Trimboli said:
Right. This will still generate a new console window, but the variables
and history and so on from the old window will be carried over.

Although what "David Trimboli" says is completely true, however, it is
possible to use the environment belonging to the cmd window that
executed "runas", rather than initializing the user's environment set
belonging to the target user of the "runas" command.

This is done with the [/env] switch.

Type : [ runas /? ] for help.

For more help, look up RUNAS in the Window's Help and Support Centre.

==

Cheers, Tim Meddick, Peckham, London. :)




sali said:
is it posible to run "runas" command *without* having started the new
cmd instance, i mean, in the same console window, inheriting previous
cmd history and env vars? something like "su" command in unix/linux

thnx!
 
M

Michael Wojcik

That's not what the su command does, so the question as presented
isn't meaningful. su exec's a new process. By default that's a shell
process, and it's a child of su, which is a child of the shell in
which the user ran su, so it inherits (most) of that shell's environment.

It only inherits the parent shell's command history if the shell makes
provisions for that - typically by keeping the command history in a
file associated with the tty name, so the new child shell can find it.

Taking "Windows" above to be "cmd.exe console windows", that second
sentence is true, though it's a property of cmd.exe and has nothing to
do with the window itself (so introducing the term isn't particularly
useful). But certainly many processes other than "the window manager"
(whatever that's supposed to refer to) are written to deal with
multiple tokens, so the second sentence is inaccurate and misleading,
if not outright wrong.

It's just a matter of parameters to CreateProcessAsUser: set
lpEnvironment to null to inherit the caller's environment, and set
dwCreationFlags to 0 to inherit the caller's console. Use LogonUser
first to get the primary token based on username and password, and
then CreateProcessAsUser to create a new cmd.exe in the same console
window.

However, neither the MKS su nor any other such program would change
the token of the current cmd.exe. They all start a new shell process.
The environment can, of course, be inherited by setting the
lpEnvironment parameter to null (though Unix su typically builds a new
environment, removing "unsafe" environment settings such as
dynamic-linker options). Since cmd.exe keeps its history in process
private memory, though, there's no way for the child cmd.exe to
inherit that.
Yes, if you write a custom shell that uses a console-style window, you
could write it to include access to multiple user contexts. But the
original question asked about instances of cmd, not other shells.
There's nothing special about cmd.exe in this regard. It works just as
any of the shells shipped with MKS do.
Nonono, if that word hadn't been the first word of a sentence, it would
have been lowercase. Not "Windows operating system," but "instance of a
window on the screen."
Nothing prevents a process with a visible window from switching
tokens, if it's written to do so. cmd.exe isn't, but that has nothing
to do with the fact that it owns a window on the desktop.
Let me rephrase. "The CMD shell doesn't deal with user contexts, so the
window in which it runs is always assumed to be of a single context."
Again, nothing to do with windows. It's a question of the security
token under which each thread in the process is running. cmd.exe
always uses the token with which it was created, but that's only
because it wasn't written to do something different.
The original poster wanted to know if you could force an instance of CMD
to jump to a different user context, or a different instance of CMD
under a different user context, in the same window. You can't.
I'm not so sure about that, either. I haven't tried it, but with
sufficient permissions I believe this ought to work:

- Get process ID of a cmd.exe process (trivial if the current process
is a child of that cmd.exe process)
- Create primary token with LogonUser
- Use DuplicateHandle to dup the token into the cmd.exe process
- Use any suitable code injection technique to get cmd.exe to call
ImpersonateLoggedOnUser(new-token) in its main thread

For the injection, I'd probably use WriteProcessMemory to build a
function A in cmd.exe that located the return address on the top of
the main thread's stack, saved it, and changed it to point to a new
block of code B (standard return-smashing technique). Block B would
make the ImpersonateLoggedOnUser call and then jump to the saved old
return address, letting the main thread continue with its business.
Then invoke the function A using CreateRemoteThread.

Of course, I haven't looked at how cmd.exe works. It may not create
new processes from its main thread, or do something else that'd
prevent that token from being inherited by new processes.

Hmm... come to think of it, CreateProcess uses the process token, not
the calling thread's impersonation token, doesn't it. So more radical
violence to the running cmd.exe process would likely be necessary, or
processes started by cmd.exe wouldn't run in the new security context.
(Builtin commands and operations, such as opening files for
redirection, should.) One possibility would be to suspend the main
thread and have the injected code take over all cmd.exe processing,
but substituting CreateProcessAsUser for CreateProcess; this would
require knowing enough about cmd.exe's internals that it's not really
worth doing (simpler to create a patched cmd.exe).

At any rate, though, the point is it's not safe to simply declare that
it's impossible to change the security context of a process.
 
T

Tim Meddick

Michael,
I find your comments to be overly critical and generally unhelpful.

I believe that, in these groups, one should endeavour to tailor the answers to the
general level of detail that was in the Original Poster's question.

In that, you have totally over-complicated your answer to the extent that I think the
OP will have not the slightest clue of what you are on about.

We give advice according to the level of knowledge we possess and, with reference to
this, it is obvious that David Trimboli knows what he is talking about.

It is of little interest to the rest of us to witness an argument on obscure detail
that becomes ever more in-depth until the relevance to anything useful becomes lost.

In short, I think that you have lost the benefit of overview that could have made
your contribution of any value to the most important person here - the one who asks
for help in the first place.

==

Cheers, Tim Meddick, Peckham, London. :)
 
Ad

Advertisements

S

sali

I believe that, in these groups, one should endeavour to tailor the
answers to the general level of detail that was in the Original Poster's
question.
there are allways 'short' and 'long' answers. 'short' consisting of 'yes' or
'no', and 'long' ones with background explanations

regarding the original question: "am i missing something to be able to run
'runas' in the same console inside 'cmd.exe'", it seems that it isn't
possible [there are no hidden undocumented trick, or registry tweaking], but
all infos presented here, i find usefull

although i had not reposted for weeks, i monitor the thread
 
M

Michael Wojcik

Tim said:
I find your comments to be overly critical and generally
unhelpful.
A shame, but I'm afraid I can't help you with that.

I am concerned, though. If you found *my* post - the very soul of
sweet reason, unaccountably missing the vulgarity, outrage, attacks ad
hominem and ad baculum, and other brickbats of the time-honored flame
- "overly critical", and so much so that you felt compelled to
respond, then I fear you are not temperamentally suited to reading
Usenet. At the very least, you will find it an exhausting and tiresome
experience.
I believe that, in these groups, one should endeavour to tailor the
answers to the general level of detail that was in the Original Poster's
question.
You are welcome to your belief. I have been reading and posting to
Usenet since 1991, and I have been studying the medium as a rhetoric
scholar since 1995, and I have different beliefs.
In that, you have totally over-complicated your answer to the extent
that I think the OP will have not the slightest clue of what you are on
about.
The strength of Usenet - indeed, its reason for existence - has always
been network effects, and particularly the ability of a pool of
respondents with varying expertise to bring new insights to a subject.
Consequently, the broad convention here has always been to assume the
OP, and other readers, are either competent to understand technical
responses, or equipped to achieve such competency if they are so
inclined. Assuming they are uneducated dimwits is neither polite nor
productive.
We give advice according to the level of knowledge we possess and, with
reference to this, it is obvious that David Trimboli knows what he is
talking about.
I am not at all sure that *is* obvious, though you state it in such
vague terms it's not clear to me precisely what you mean. In any case,
though, what Mr Trimboli, or anyone else here, *knows* is beside the
point. This is Usenet; it is not telepathy, or an interrogation, or a
job interview. All we have is what people *post*.
It is of little interest to the rest of us
Out of curiosity, when did the massed readers of three groups elect
you their representative?
to witness an argument on
obscure detail that becomes ever more in-depth until the relevance to
anything useful becomes lost.
And by what special insight do you determine what is relevant to
everyone reading the thread?
In short, I think that you have lost the benefit of overview that could
have made your contribution of any value to the most important person
here - the one who asks for help in the first place.
Your understanding of Usenet is remarkable. Probably indefensible, but
remarkable nonetheless.
 
T

Tim Meddick

I appreciate what you are saying but, concerning the level of detail in technical
background - don't you think there's a line to be drawn somewhere?

Or is it right for people to always get drawn into arguments over sub-atomic detail
so that eventually every other person involved has no idea what is really being
discussed, and, what is more, has no interest in it either?

Surly, the most important point is to try to actually answer, in as practical way as
possible, the original question - and not get so carried away that that is forgotten!

==

Cheers, Tim Meddick, Peckham, London. :)




sali said:
I believe that, in these groups, one should endeavour to tailor the answers to the
general level of detail that was in the Original Poster's question.
there are allways 'short' and 'long' answers. 'short' consisting of 'yes' or 'no',
and 'long' ones with background explanations

regarding the original question: "am i missing something to be able to run 'runas'
in the same console inside 'cmd.exe'", it seems that it isn't possible [there are
no hidden undocumented trick, or registry tweaking], but all infos presented here,
i find usefull

although i had not reposted for weeks, i monitor the thread
 
A

Al Dunbar

There definitely is line to be drawn, but whose should it be? And should the
line exclude disagreements about where it should be drawn?

/Al

Tim Meddick said:
I appreciate what you are saying but, concerning the level of detail in
technical background - don't you think there's a line to be drawn
somewhere?

Or is it right for people to always get drawn into arguments over
sub-atomic detail so that eventually every other person involved has no
idea what is really being discussed, and, what is more, has no interest in
it either?

Surly, the most important point is to try to actually answer, in as
practical way as possible, the original question - and not get so carried
away that that is forgotten!

==

Cheers, Tim Meddick, Peckham, London. :)




sali said:
I believe that, in these groups, one should endeavour to tailor the
answers to the general level of detail that was in the Original Poster's
question.
there are allways 'short' and 'long' answers. 'short' consisting of 'yes'
or 'no', and 'long' ones with background explanations

regarding the original question: "am i missing something to be able to
run 'runas' in the same console inside 'cmd.exe'", it seems that it isn't
possible [there are no hidden undocumented trick, or registry tweaking],
but all infos presented here, i find usefull

although i had not reposted for weeks, i monitor the thread
 
J

Jonathan de Boyne Pollard

It only inherits the parent shell's command history if the shell makes provisions for that - typically by keeping the command history in a file associated with the tty name, so the new child shell can find it.




... which is unnecessary on Win32, since command history is not (in the system-supplied command interpreter at any rate) a function of the command interpreter program.



Since cmd.exe keeps its history in process private memory, though, there's no way for the child cmd.exe to inherit that.



No, it really doesn't.&nbsp; This is one place where the designs of the Win32 API and of the POSIX API differ.&nbsp; Console aliases and command history are actually directly part of the console, not implemented within individual command interpreter processes.&nbsp; (Of course, for command interpreters such as Take Command and 4NT, which implement their own command editing, aliasing, and history mechanisms, they are.)&nbsp; There is a mostly undocumented console API (AddConsoleAlias, GetConsoleCommandHistory, SetConsoleHistoryInfo, and so forth) that is used by CMD for accessing them.
 
Ad

Advertisements

J

Jonathan de Boyne Pollard

I believe that, in these groups, one should endeavour to tailor the answers to the general level of detail that was in the Original Poster's question.



The Perl newsgroups have been interesting sources of stock responses, including the one with the chocolate-covered bananas and the European currency systems.&nbsp; Here's another one, from comp.lang.perl.misc, that has been around for almost ten years, now:




Get real! This is a discussion group, not a helpdesk. You post something, we discuss its implications.



It is a valid point.&nbsp; These are discussion groups, not helpdesks.&nbsp; We are volunteers, not paid support staff.&nbsp; And we most definitely are not restricted by some imaginary bounds set by the "original poster", especially since such "original posters" are here oftentimes because they don't know stuff, including not even having proper definitions of their problems.&nbsp; We are certainly not restricted from pointing out where things are downright wrong, just because you (not even M. Sali, but you) think that the subject is a technical one.&nbsp; These are technical newsgroups.&nbsp; If you cannot handle or don't like technical subjects, and concomitant discussions, which will include people who actually do know what they're talking about giving all of those nitty-gritty technical details of how things can and do work that you think to be "unhelpful" and "complicated", then you've subscribed to the wrong newsgroups.




We give advice according to the level of knowledge we possess and, with reference to this, it is obvious that David Trimboli knows what he is talking about.



The thing is: That isn't obvious, and you really should have seen that.&nbsp; What should have been obvious to you is that M. Trimboli is wrong, given the simple existence of a utility that not only does what M. Trimboli is saying to be impossible, but even has the same name as the utility that the original poster asked for a Windows equivalent to.&nbsp; There really isn't even the excuse you're making that this discussion is hard to follow.&nbsp; "On the contrary, there exists a program that does that very thing, and there it is.&nbsp; Such utilities work in the following fashion, and Win32 in fact works in the following way, ..." isn't exactly a complex and abstruse argument.
 
M

m

LOL! most of us just know the registry hacks for this stuff; but I am glad that there _is_ an API exported somewhere for this stuff ;)
It only inherits the parent shell's command history if the shell makes provisions for that - typically by keeping the command history in a file associated with the tty name, so the new child shell can find it.


... which is unnecessary on Win32, since command history is not (in the system-supplied command interpreter at any rate) a function of the command interpreter program.

Since cmd.exe keeps its history in process private memory, though, there's no way for the child cmd.exe to inherit that.

No, it really doesn't. This is one place where the designs of the Win32 API and of the POSIX API differ. Console aliases and command history are actually directly part of the console, not implemented within individual command interpreter processes. (Of course, for command interpreters such as Take Command and 4NT, which implement their own command editing, aliasing, and history mechanisms, they are.) There is a mostly undocumented console API (AddConsoleAlias, GetConsoleCommandHistory, SetConsoleHistoryInfo, and so forth) that is used by CMD for accessing them.
 
T

Tim Meddick

You'll go blind if you're not carful...

==

Cheers, Tim Meddick, Peckham, London. :)




message I believe that, in these groups, one should endeavour to tailor the answers to the
general level of detail that was in the Original Poster's question.
 
Ad

Advertisements

M

Michael Wojcik

Jonathan said:
No, it really doesn't. This is one place where the designs of the Win32
API and of the POSIX API differ. Console aliases and command history
are actually directly part of the console, not implemented within
individual command interpreter processes. (Of course, for command
interpreters such as Take Command and 4NT, which implement their own
command editing, aliasing, and history mechanisms, they are.) There is
a mostly undocumented console API (|AddConsoleAlias|,
|GetConsoleCommandHistory|, |SetConsoleHistoryInfo|, and so forth) that
is used by |CMD| for accessing them.
Thanks for the correction. I should have checked that before posting.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Console 1
recovery console 1
recovery console 2
Recovery Console 1
RECOVERY CONSOLE 1
Installing from console. 1
Recovery console keyboard layout 3
How to run recovery console? 1

Top