TCL script: test permissions - permissions

How can I check if a script is running with root-privileges?
I am using the following code, but it uses linux commands to get the user id so it would not work on m$ win. Is there an platform independent approach to handle this problem ?
if { [exec id -u] eq 0 } {
//nice, let us destroy something!
} else {
//sorry. you are not root
}

Windows has no root privileges.
Maybe the SYSTEM account or a member of the Administrators group is what you want.
There is no known platform independent approach that I know of.
I suggest branching for different OS.
On Windows: To check if the current process runs as a member of the Administrators group you could do the following thing:
package require twapi
set token [twapi::open_process_token]
set groups [twapi::get_token_groups_and_attrs $token]
twapi::close_token $token
if {[dict exists $groups S-1-5-32-544] && {enabled} in [dict get $groups S-1-5-32-544]} {
puts "I run as administrator"
} else {
puts "No admin rights"
}
This requires twapi, a great package for windows.
The Administrators' SID is hardcoded, because it is the same on every system, while the name of the Administrators group is not (on my system it is "Administratoren").
You should check if the group is enabled because starting with Windows Vista there is UAC, which will list the Administrators' group SID (S-1-5-32-544) for members of this group, but with a use_for_deny_only flag. (Only when invoked with the "run as administrator", this group will be enabled.)
On Unix/Linux I suggest using TclX.
here it is simple:
package require TclX
if {[id userid]} {
puts "Not root"
} else {
puts "root"
}
This might even work with OS/X, but I'm not sure.
PS: Don't be evil.

In perl you can write following to get user name of under which the script is running as follows (independent of OS)
print "Current username is " . (getpwuid($<))[0] . "\n";
I don't know muhc about TCL though - but you can look here
how to do getpwnam/getpwuid etc in tcl
and here http://wiki.tcl.tk/1649

Related

How to Impersonate Impala queries on Superset

I'm setting up Superset (0.36.0) in production Mode (with Gunicorn), and I would like to set up impersonate while running Impala queries on my Kerberized Cluster, to each user of Superset have privilegies on tables/databases like he has on Hive/Hue/HDFS. I've tried to set "Impersonate the logged on user" to true in my database config, but it's not changing the user that is running the query, it's always using the celery-worker user.
My database config is:
Extras:
{
"metadata_params": {},
"engine_params": {
"connect_args": {
"port": 21050,
"use_ssl": "True",
"ca_cert": "/path/to/my/cert.pem",
"auth_mechanism": "GSSAPI"
}
},
"metadata_cache_timeout": {},
"schemas_allowed_for_csv_upload": []
}
My query resume in Cloudera Manager (5.13):
How can I enable Impersonate correctly in my Superset? Maybe there is something related to the config impala.doas.user in HiveServer2 connection, but I don't know how to config this properly.
I faced the same issue and I was to get it working for hive. The issue seems to be in the file hive.py located under the path ${YOUR_INSTALLATION_PATH}/superset/db_engine_specs
If you just comment out line 435, it should work. Unfortunately, I don't understand python well enough to tell you the exact reason.
I found this by brute force by running the source code and putting log statements
if (
backend_name == "hive"
# comment this line
# and "auth" in url.query.keys()
and impersonate_user is True
and username is not None
):
configuration["hive.server2.proxy.user"] = username
return configuration
Alternatively, if you do not want to modify the source code, you can modify the URL while creating the data source in superset as :
hive://<url>/default?auth=NONE ( when there is no security )
hive://<url>/default?auth=KERBEROS
hive://<url>/default?auth=LDAP

hubot-auth not authenticating

I have just installed hubot and I'm trying some basic tests.
I have this basic script in /scripts:
module.exports = (robot) ->
robot.respond /myscript status/i, (msg) ->
if robot.auth.hasRole(msg.envelope.user, 'test')
msg.reply "Success"
else
msg.reply "Sorry. Need 'test' role."
I issue the appropriate Slack commands:
schroeder has test role
"OK, schroeder has the 'test' role."
myscript status
"Sorry. Need 'test' role."
I have:
tried to reverse the logic (if vs unless)
verified that the scripts are being updated (by changing responses)
verified that the redis backend is storing the role (connected via redis-cli and inspected the key).
After re-reading all the documentation and looking up bug reports I still cannot see what I'm missing. It has got to be something simple, but I'm out of ideas. It is almost as though the script is not able to view the stored role (hubot-auth can, but my script cannot).
Even though on start, hubot says that it is connecting to a local Redis server:
INFO hubot-redis-brain: Using default redis on localhost:6379
It isn't... At least not in a way that you would expect.
If redis is, in fact running, you should get an extra message:
INFO hubot-redis-brain: Data for hubot brain retrieved from Redis
That message does not appear and there is no warning or error that Redis is not running.
If you have not set up hubot-redis-brain properly, you will get strange errors and inconsistencies, like hubot-auth role check functions failing.
In addition, I found that even after I set Redis up properly, my test script did not work. Even though all the tutorials I found test the msg.envelope.user, this did not work for me. I needed to use the msg.message.user.name and resolve with the brain class:
module.exports = (robot) ->
robot.respond /fbctf status/i, (msg) ->
user = robot.brain.userForName(msg.message.user.name)
if robot.auth.hasRole(user, 'test')
msg.reply "Success"
else
msg.reply "Sorry. Need 'test' role."

Why can't local Windows 7 Pro machine read its own WMI values?

As part of a larger .Net 4.0 program I have a piece that queries the WMI for a list of network adapters and from that creates a list<> of physical adapters with MAC addresses.
It works on the machines I've tried it on, but when sent to the client, the list is empty. If they run IPCONFIG /ALL at a command prompt the MACs are listed.
My first thought is that there is a group policy in place preventing the enumeration, but everything I've found so far points to group policies that affects remote access through the firewall.
I've tried it locally as both a standard user and administration user, both provide the same list.
The empty query does not generate an exception.
I could ask them to go to the machines and check individual permissions, but since this seems to be a group issue that seems to be the wrong direction. What am I missing?
public static List<WmiNetworkInterfaceItem> QueryphysicalNetworkInterfaces()
{
ManagementObjectSearcher searcher =
new ManagementObjectSearcher("root\\CIMV2",
"SELECT * FROM Win32_NetworkAdapter");
List<WmiNetworkInterfaceItem> result = new List<WmiNetworkInterfaceItem>();
foreach (ManagementObject queryObj in searcher.Get()) {
if (queryObj["PhysicalAdapter"].Equals(true)) {
if (queryObj["AdapterTypeId"] != null) {
if (queryObj["AdapterTypeId"].ToString().Equals("0")) {
WmiNetworkInterfaceItem wmiNetworkInterfaceItem = new WmiNetworkInterfaceItem();
wmiNetworkInterfaceItem.Name = ManagementObjectPropertyString(queryObj["Name"]);
wmiNetworkInterfaceItem.MacAddress = ManagementObjectPropertyString(queryObj["MACAddress"]);
wmiNetworkInterfaceItem.PhysicalAdapter = queryObj["PhysicalAdapter"].Equals(true);
wmiNetworkInterfaceItem.AdapterType = ManagementObjectPropertyString(queryObj["AdapterType"]);
wmiNetworkInterfaceItem.AdapterTypeId = -1;
int.TryParse(ManagementObjectPropertyString(queryObj["AdapterTypeId"]), out wmiNetworkInterfaceItem.AdapterTypeId);
wmiNetworkInterfaceItem.Description = ManagementObjectPropertyString(queryObj["Description"]);
wmiNetworkInterfaceItem.PermanentAddress = ManagementObjectPropertyString(queryObj["PermanentAddress"]);
result.Add(wmiNetworkInterfaceItem);
}
}
}
}
return result;
}
Using the WBEMTest utility included with Windows as suggested by user atp_09 in comments, I was able to have the customer query his machine. Using this query exactly one adapter was returned in both standard and administrative user accounts indicating there was nothing in the machine preventing this from working.
SELECT * FROM Win32_NetworkAdapter where PhysicalAdapter = true
Upon further review there was an error in how I later dealt with the list with a single response.

How to define a driver for tclodbc?

I want to use tclodbc from Linux environment to connect to a MS SQL server. I have the driver (freeTDS) and the connection string. But I don't know how to configure the driver to be used by tclodbs. There is a command
database configure operation driver attributes
But I don't know what to put as operation and attributes, and whether this is the right command.
Related to my question: Accessing Microsoft SQL Server from Tcl running on GNU/Linux
OK, here's my take based on these guides about how to make a DSN-less connection using the FreeTDS driver.
I've tested it a Debian Lenny system having tclodbc 2.5-5, unixodbc 2.2.11 and libdbd-freetds 0.8.2-1-4.1 and tcl 8.4.16-2 installed against an instance of Microsoft SQL Server 2005.
package require tclodbc
proc cs_append {varName args} {
set alen [llength $args]
if {$alen < 2 || $alen % 2 != 0} {
return -code error "Wrong # args: should be varName key value ?key value?"
}
upvar 1 $varName qs
foreach {key value} $args {
if {$qs ne ""} {
append qs \;
}
append qs $key = \{ [string map {\{ \\\{} $value] \}
}
}
set user test
set pass secret
set cs ""
cs_append cs DRIVER FreeTDS UID $user PWD $pass \
Server myserver.domain.local \
ClientCharset UTF-8 \
APP "My test app"
database connect db $cs
foreach row [db {select * from MyDatabase..MyTable}] {
puts $row
}
db disconnect
Some notes:
The FreeTDS driver must be known to the ODBC subsystem by means of it being registeded in the /etc/odbcinst.ini file. I suppose that at least on my system appropriate packages take care of this by themselves but you'd better verify if you have FreeTDS registered in that file, otherwise that DRIVER=FreeTDS bit in the connection string won't work as ODBC will have no idea how to load the named driver library.
The ClientCharset and APP connection string parameters do not work in my case. While I can live with the second, the first one sucks big time because in this case the character data is returned in some botched encoding.
But there's no such problem when I use named server from the /etc/freetds/freetds.conf file using the ServerName=THAT_SERVER instead of Server=SERVER_HOST in the connection string. Unfortunately, this kind of defeats half of the purpose of using DSN-less setup.
Quite possibly it's a bug in my version of the FreeTDS driver, and I have a really outdated system here, so YMMV and you better check yourself on your system.
If we look at the documentation, we see that there are 6 operations, of which the one you probably want is add_dsn. An example is included (below, with a small correction):
set driver "Microsoft Access Driver (*.mdb)"
set attributes [list "DSN=mydsn" "DBQ=c:\mydb.mdb" "FIL=MS Access"]
database configure add_dsn $driver $attributes
I'm afraid you'll have to consult the FreeTDS documentation to get the right collection of attributes, but I think (based on this evidence) that you'll have the driver being FreeTDS and the attributes might be OK if it is an empty list (or with just TDS_Version=5.0 in it). I really don't know too much about configuring ODBC…

How do I assign limited console program access to IIS 6?

Let's say I have a simple console program to fetch a list of files given the folder name. I want to call the console program using PHP code on a site that is running on a unique Windows user account (ie not the default web user account). Is there a way I can allow the Windows account access to the console program without giving it blanket access to cmd.exe? I'm working with IIS 6 on Windows 2003 Server.
Update:
Here's some code I've tried using popen()
$reg_cmd = '"C:\WINDOWS\system32\notepad.exe"' ;
$error = '';
$handle = popen($reg_cmd, 'r');
if (!$handle){
$last_error = error_get_last();
$error = $last_error['message'];
}
else{
while (!feof($handle)) {
$result .= fread($handle, 2096);
}
}
pclose($handle);
$error ends up containing either:
popen("C:\WINDOWS\system32\notepad.exe",r) [function.popen]: Result too large
OR
popen("C:\WINDOWS\system32\notepad.exe",r) [function.popen]: No such file or directory
I've no idea why the error message is inconsistent. The results were even less promising using proc_open().
Can you use proc_open() instead of exec()?
From version 5.2.1 proc_open() no longer requires you to give access to cmd.exe.