If you want to avoid the console windows popping up, use wperl.exe instead of perl.exe for the helper process. Note that STDIN etc. will be unavailable.
| [reply]
[d/l]
[select] |
But the way to pass the password back to the caller is via STDOUT!
| [reply] |
| [reply]
[d/l] |
the parent just get stalled at the $pipe->Connect.
Um..?
async{
my $pipe = Win32::Pipe->new( 'MyPipe' );
while( 1 ) {
$pipe->Connect;
$pipe->Write( 'The quick brown fox' );
$pipe->Disconnect;
}
}->detach;
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
Also, a minor issue I have found with extprog is that a console window pops up briefly. Besides the visual ugliness what really worries me is if that could cause the helper invocation to fail on contexts lacking a GUI environment. For instance, when called from the task scheduler, a web server, or any other program not started inside an user session.
Hm. Given that you aren't spawning the program, none of the usual tricks to prevent the window popping will work.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
But what really bothers is not the windows popping but if it will always be able to pop...
| [reply] |
If you have to go the private file route, this may help. It creates a file that can only be read by the current userid, and writes the password to it. It then waits for keyboard input and deletes the file.
I've verified that other users, including administrators cannot read or delete the file, nor even inspect its permissions.
Also, in theory, by using FILE_ATTRIBUTE_TEMPORARY, the contents may never actually be written to the disk, and (assuming a small file and a system file cache that is not overrun) only ever exist in cache. (In theory!)
#include <windows.h>
#include <sddl.h>
#include <stdio.h>
#include <conio.h>
#include <Lmcons.h>
#include "debug.h"
#define TESTFILENAME "PermissionsTest.txt"
int main( int argc, char **argv ) {
char userName[ UNLEN+1 ];
char sid[ 400 ];
char *stringSID;
char domainName[ 256 ];
SID_NAME_USE sidType;
char pswd[] = "The quick brown fox";
char ssdTemplate[] = "O:%sD:P(A;;FA;;;%s)";
char ssd[1024];
SECURITY_DESCRIPTOR *psd = NULL;
SECURITY_ATTRIBUTES sa = { sizeof( SECURITY_ATTRIBUTES ), NULL, 0
+};
ULONG sdSize, unSize = sizeof( userName ), sidSize = sizeof( sid )
+, dnSize = sizeof( domainName ), written;
HANDLE h;
DIEIF( !GetUserName( userName, &unSize ), NULL );
DIEIF( !LookupAccountName( NULL, userName, sid, &sidSize, domainNa
+me, &dnSize, &sidType ), NULL );
printf( "Got sid\n" );
DIEIF( !ConvertSidToStringSid( sid, &stringSID ), NULL );
printf( "SID (as string): '%s'\n", stringSID );
sprintf_s( ssd, sizeof(ssd), ssdTemplate, stringSID, stringSID );
printf( "SSD: '%s'\n", ssd );
DIEIF( !ConvertStringSecurityDescriptorToSecurityDescriptor( ssd,
+SDDL_REVISION_1, &psd, &sdSize ), NULL );
printf( "psd:%x sdSize: %d\n", psd, sdSize );
sa.lpSecurityDescriptor = psd;
DIEIF( ( h = CreateFile(
TESTFILENAME, GENERIC_WRITE, FILE_SHARE_READ, &sa, CREATE_
+ALWAYS,
FILE_ATTRIBUTE_TEMPORARY, NULL
)) == INVALID_HANDLE_VALUE, NULL
);
printf("File created\n" );
DIEIF( !WriteFile( h, pswd, sizeof( pswd ), &written, NULL ), NULL
+ );
printf( "File written '%s'\n", pswd );
while( !_kbhit() ) Sleep( 1 );
printf( "Closing file\n" );
DIEIF( !CloseHandle( h ), NULL );
DIEIF( !DeleteFile( TESTFILENAME ), NULL );
return 0;
}
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
Anyway, I still have to check that the file handle survives the full chain of program calls (perl -> sshg3 -> cmd -> helper)
It doesn't, the file handle is not inherited by sshg3 children.
| [reply]
[d/l] |
| [reply]
[d/l]
[select] |
Well, that led me into using OpenProcess+DuplicateHandler to get the handler from the perl process into the helper and it works!
On the other hand, how secure is that? I guess only processes from the same user would be able to reopen handlers.
I will post a link to the code once I clean it.
| [reply] |