We Keep Coding

Fabric2 CLI: gracefully switch SSH user

I am using Invoke/Fabric with boto3 to create an AWS instance and hand it over to an Ansible script. In order to do that, a few things have to be prepared on the remote machine before Ansible can take over, notably installing Python, create a user, and copy public SSH keys.
The AWS image comes with a particular user. I would like to use this user only to create my own user, copy public keys, and remove password login afterwards. While using the Fabric CLI the connection object is not created and cannot be modified within tasks.
What would be a good way to switch users (aka recreate a connection object between tasks) and run the following tasks with the user that I just created?
I might not go about it the right way (I am migrating from Fabric 1 where a switch of the env values has been sufficient). Here are a few strategies I am aware of, most of them remove some flexibility we have been relying on.
Create a custom AMI on which all preparations has been done already.
Create a local Connection object within a task for the user setup before falling back to the connection object provided by the Fabric CLI.
Deeper integrate AWS with Ansible (the problem is that we have users that might use Ansible after the instance is alive but don't have AWS privileges).
I guess this list includes also a best practice question.

The AWS image comes with a particular user. I would like to use this user
only to create my own user, copy public keys, and remove password login
afterwards. While using the Fabric CLI the connection object is not created
and cannot be modified within tasks.
I'm not sure this is accurate. I have switched users during the execution of a task just fine. You just have to make sure that all subsequent calls that need the updated env use the execute operation.
e.g.
def create_users():
run('some command')
def some_other_stuff():
run('whoami')
#task
def new_instance():
# provision instance using boto3
env.host = [ ip_address ]
env.user = 'ec2-user'
env.password = 'sesame'
execute(create_users)
env.user = 'some-other-user'
execute(some_other_stuff)

Create service principal programmatically in Azure Python API

How can I, using the Azure Python API, create a full set of credentials that can later be used to start and deallocate all VMs in a named resource group, without any other permissions?
I have thoroughly researched the example code and both official and unofficial documentation, but I don't even know where to start...
I know I will need a tenant ID, client ID, client secret and subscription ID. Which of those can I make using an API, and how would I go about assigning roles to allow for starting/deallocating VMs of an existing resource group?
Sample code highly sought after, but will take any hint!

You need the azure-graphrbac package to create a Service Principal:
https://learn.microsoft.com/python/api/overview/azure/activedirectory
The closer to a sample might be this unittest:
https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/graphrbac/azure-graphrbac/tests/test_graphrbac.py
For role and permissions, you need azure-mgmt-authorization:
https://learn.microsoft.com/python/api/overview/azure/authorization
Best sample for this one, is probably the sub-part of this sample:
https://github.com/Azure-Samples/compute-python-msi-vm#role-assignement-to-the-msi-credentials
"msi_identity" is a synonym of "service principal" in your context.
Note that all of this is supported by the CLI v2.0:
https://learn.microsoft.com/cli/azure/ad/sp
https://learn.microsoft.com/cli/azure/role/assignment
It might be interested to test the CLI in --debug mode and sniffing in the code repo at the same time:
https://github.com/Azure/azure-cli
(full disclosure, I work at MS in the Azure SDK for Python team)

Make ms access database trusted for all users on network disc

I have made a GUI using python and tkinter, which allows the user to choose search criterias to be used in an MS Access query. Upon a buttonclick, the script opens Access and runs a macro which in turn launches a function that reads the user input, performs the query and prints reports. The code used to do this is:
objAccess = win32com.client.Dispatch("Access.application")
objAccess.Visible = False
objAccess.OpenCurrentDatabase(filepath)
objAccess.DoCmd.RunMacro("Macro1")
objAccess.Quit()
My problem is that I want to put the database and the python script on a network drive so that my coworkers may use the script to generate reports without having to open the database in Access (and inevitably make inadvertent changes). Whenever the script is run for the first time from someone else's PC, it will not complete, as the macros have not been enabeled from that pc. If they open the database and enable macros and make the document "trusted", the script will work fine.
What I want to know is if there is any way to enable macros permanetly for all users for that particular Access database, or if I can modify my script to check if the database has macros enabled or not, and to enable macros if they are disabled.
I know that the disabling of macros is a security measure, so I guess I may just have to ask my users to manually enable macros before running the script. Not very elegant.

There are two ways of enable macro permanently.
Trusted Location: A path/location, where stored databases are always trusted.
Trusted Publisher: Sign database with certification
You can set/edit them in the trust center settings in File > Options > Trust Center > Trust Center Settings.
But you have to set it up for every user/access-installation at least once.
Here is the official link from MS how to do it:
https://technet.microsoft.com/en-us/library/dn166703.aspx
Be aware, that Microsoft does not recommend to set network pathes as trusted locations. Also, you should consider #Krish KMs comment suggestion, to create a local front end for the users. This would also need a trusted location or publisher, but not on network drive, but on a local drive.

Postgres: is set_config(). current_setting() a private/robust stack for application variables?

In my application I have triggers that need access to things like user id. I am storing that information with
set_config('PRIVATE.'|'user_id', '221', false)
then, while I am doing operations that modify the database, triggers may do:
user_id = current_setting('PRIVATE.user_id');
it seems to work great. My database actions are mostly from python, psycopg2, once I get a connection I'll do the set_config() as my first operation, then go about my database business. Is this practice a good one or could data leak from one session to another? I was doing this sort of thing with the SD and GD variables in plpython, but that language proved too heavy for what I was trying to do so I had to shift to plpgsql.

While it's not really what they're designed for, you can use GUCs as session variables.
They can also be transaction scoped, with SET LOCAL or the set_config equivalent.
So long as you don't allow the user to run arbitrary SQL they're a reasonable choice, and session-local GUCs aren't shared with other sessions. They're not designed for secure session-local storage but they're handy places to stash things like an application's "current user" if you're not using SET ROLE or SET SESSION AUTHORIZATION for that.
Do be aware that the user can define them via environment variables if you let them run a libpq based client, e.g.
$ PGOPTIONS="-c myapp.user_id=fred" psql -c "SHOW myapp.user_id;"
myapp.user_id
---------------
fred
(1 row)
Also, on older PostgreSQL versions you had to declare the namespace in postgresql.conf before you could use it.

Why does PyUSB / libusb require root (sudo) permissions on Linux?

I have been toying around with PyUSB lately, and found that it works beautifully on Linux (Ubuntu has libusb 0.1 and 1.0, as well as OpenUSB)... but only if I run the program with root privileges (with sudo, of course).
Can anyone tell me why it requires elevated privileges and, more importantly, if I can change the permissions somehow to make it work for normal user accounts?

You can change the permissions of your usb device node by creating a udev rule.
e.g. I added the following line to a file in /etc/udev/rules.d/
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664", GROUP="usbusers"
This sets the owner of the device node to root:usbusers rather than root:root
After adding myself to the usbusers group, I can access the device.

See the answer that I gave here:
How can I comunicate with this device using pyusb?
Namely:
Set up a udev rules file for the specific device that you want normal users to be able to access. This will define the vendor id, the product id and a group.
The vendor and product id's can be found using the lsusb command.
1.
Create a udev rules file
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="171b", ATTRS{idProduct}=="2001", MODE="660", GROUP="plugdev"
Put this in a file called (for example) /lib/udev/rules.d/50-YourSoftwareName.rules (dig around in man udev for file naming rules)
NOTE: The old naming convention used /etc/udev/rules.d/filename.rules, that has changed.
2.
add the user names to the plugdev group
adduser username plugdev
3.
force the udev system to see your changes
sudo udevadm control --reload (that is minus minus reload)
sudo udevadm trigger
4.
unplug and replug the device
or
reboot your machine
The end result should be that all members of the group plugdev will now be able to access the device.
EDIT:
Note that on some systems the group plugdev may not be the group that you need. It can also be the group input in my experience, depending on what you are plugging in.

libusb allows you to manipulate arbitrary USB devices in arbitrary ways. You could format an external USB harddisk, for example.
In general, all direct hardware access requires root privileges, although I guess that actually full root privileges are not required, you should be fine with just CAP_SYS_RAWIO.