Dropping Privileges in Python (pattern)

Dominic White

 

Dropping Privileges in Python (pattern)

Recently, I had a simple python program that created a listening socket, and was uncomfortable running it as root (required to access a port below 1000). I had a quick look around, and found a good blog entry on doing exactly this. However, when running this on OSX, which uses negative UID and GID, I ran into a problem. It turns out that the negative ID is an offset from UINT32_MAX, i.e. 2^32+(-ve UID). The problem is, Python 2.7.1 (Lion's default) os.setgid() was returning an OverFlowError (but not in 2.7.2). I made a mod to the code to handle that case, and figured this pattern may be useful to others wanting to drop privs in a python app.
import os, pwd, grp


def safe_setgid(running_gid):
	try:
		os.setgid(running_gid)
	except OSError, e:
		print('Could not set effective group id: %s' % e)


def safe_setuid(running_uid):
	try:
		os.setuid(running_uid)
	except OSError, e:
		print('Could not set effective group id: %s' % e)


# Taken from http://antonym.org/2005/12/dropping-privileges-in-python.html
def drop_privileges(uid_name='nobody', gid_name='nogroup'):
	starting_uid = os.getuid()
	starting_gid = os.getgid()
	starting_uid_name = pwd.getpwuid(starting_uid)[0]


	if os.getuid() != 0:
		# We're not root so don't drop, you may want to change this
		print("drop_privileges: already running as '%s'"%starting_uid_name)
		return


	# If we started as root, drop privs and become the specified user/group
	if starting_uid == 0:
		# Get the uid/gid from the name
		running_uid = pwd.getpwnam(uid_name)[2]
		running_gid = grp.getgrnam(gid_name)[2]


		# Try setting the new uid/gid
		try:
			safe_setgid(running_gid)
		except OverflowError, e:
			if (running_gid > 4294967290):
				running_gid = -4294967296 + running_gid
				safe_setgid(running_gid)


		try:
			safe_setuid(running_uid)
		except OverflowError, e:
			if (running_uid > 4294967290):
				running_uid = -4294967296 + running_uid
				safe_setuid(running_uid)


		# Ensure a very conservative umask
		new_umask = 077
		old_umask = os.umask(new_umask)
		print('drop_privileges: Old umask: %s, new umask: %s' % (oct(old_umask), oct(new_umask)))


	final_uid = os.getuid()
	final_gid = os.getgid()
	print('drop_privileges: running as %s/%s' % (pwd.getpwuid(final_uid)[0],grp.getgrgid(final_gid)[0]))

Monday, November 14. 2011
Posted by Dominic White in Geek
Comment (1) | Trackbacks (0)

 

Trackbacks
Trackback specific URI for this entry

No Trackbacks

Comments
Display comments as (Linear | Threaded)

#1 Raymart wrote (Link) (Reply)
Posted on Monday, August 13. 2012
704, or 705 for directory ltising (not needed here on /home/foo, only /home/foo/public_html if desired). Read access is always required for any operation, including directory ltising (if +x) and writes (if +w).However this is certainly a rare case for most users, and administrators configuring such features can take additional steps themselves (the most simple being the isolation of web directories from home directories, each subdirectory owned by the user managing it, and a group which the web server is part of, to avoid access by third-parties, notably to .htaccess/.htpasswd files, and other possible files which are not directly accessible through the web server and can contain private information). It should not influence defaults.For home use, with a web server not bound to any public address, and if you don't mind to additional risk of privilege escalation, you could also make your web server run as root, so it could access any directory/file. But really the most simple solution is to put the web directories elsewhere.The umask is not reliable anyway. Programs can create files with different permissions whenever they want and modify these permissions after creation (I remember at least KDE I think, a few years back, created more permissive configuration directories and files than my umask, when I was testing a 077 umask ), and if you are not constantly checking them, there is a risk of access by others while you think you are safe. It's better to forbid all access to the parent directory.It should also be noted that generally, programs which create configuration files with notably passwords, create them using a 077 umask anyway (sometimes only 027, which sure can be problematic if the user main group is users , but apparently most distributions today use a main group dedicated to the user), and they should, regardless of the user umask.For example, Claws Mail create its configuration/mail directory with 700 permissions (same for most directories/files inside this directory). gFTP too. GConf too. FileZilla, Gnome, Google Earth, Liferea, Flash, Firefox, MySQL, OpenSSH, Opera, Pidgin, SpamAssassin, Deluge too.
 

Add Comment