Title: POSIX capabilities support
Type: enhancement Stage: patch review
Components: Extension Modules Versions: Python 3.5
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, Christian H, georg.brandl, giampaolo.rodola, gj0aqzda, loewis, nanjekyejoannah, neologix, nnorwitz, pitrou, rosslagerwall
Priority: normal Keywords: needs review, patch

Created on 2006-12-13 18:10 by gj0aqzda, last changed 2019-09-09 20:46 by nanjekyejoannah.

File name Uploaded Description Edit
patch-svn.diff gj0aqzda, 2006-12-13 18:10 POSIX capabilities patch
patch-svn-doc.diff gj0aqzda, 2006-12-19 10:48 POSIX capabilities documentation patch review
patch-20080620-1232.diff gj0aqzda, 2008-06-20 11:34 POSIX capabilities patch III review
patch-20080620-1314.diff gj0aqzda, 2008-06-20 12:15 POSIX capabilities patch IV review
Pull Requests
URL Status Linked Edit
PR 15815 open nanjekyejoannah, 2019-09-09 20:46
Messages (22)
msg51513 - (view) Author: Matt Kern (gj0aqzda) Date: 2006-12-13 18:10
Attached is a patch which adds POSIX capabilities support.  The following API functions are supported:

  * cap_clear
  * cap_copy_ext
  * cap_dup
  * cap_from_text
  * cap_get_flag
  * cap_get_proc
  * cap_init
  * cap_set_flag
  * cap_set_proc
  * cap_size
  * cap_to_text

The following API function is supported, but is broken with certain versions of libcap (I am running debian testing's libcap1, version 1.10-14, which has an issue;  I have reported this upstream):
  * cap_copy_int

The following API functions are in there as stubs, but currently are not compiled.  I need access to a machine to test these.  I will probably add autoconf tests for availability of these functions in due course:
  * cap_get_fd
  * cap_get_file
  * cap_set_fd
  * cap_set_file

The patch includes diffs to configure.  My autoconf is however at a different revision to that used on the python trunk.  You may want to re-autoconf

I've added a few API tests to
msg51514 - (view) Author: Matt Kern (gj0aqzda) Date: 2006-12-13 18:12
I should further add that I have implemented the following API calls as methods of the new CapabilityState object in addition to the standard functions:

  * cap_clear
  * cap_copy_ext
  * cap_dup
  * cap_get_flag
  * cap_set_flag
  * cap_set_proc
  * cap_size
  * cap_to_text
msg51515 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-12-16 12:28
Can you please provide documentation changes as well?
msg51516 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2006-12-16 13:25
(If you don't want to write LaTeX, it's enough to write the docs in plaintext, there are a few volunteers who will convert it appropriately.)
msg51517 - (view) Author: Matt Kern (gj0aqzda) Date: 2006-12-19 10:48
I've attached a documentation patch, which should be applied in addition to the base patch.
File Added: patch-svn-doc.diff
msg51518 - (view) Author: Matt Kern (gj0aqzda) Date: 2007-01-29 16:57
No news on these patches in a while.

To summarise, the patches are ready to go in.  The issues surrounding cap_copy_int(), cap_get_*() and cap_set_*() are pretty minor.  The vast majority of uses will be of the cap_get_proc(), cap_set_flag(), cap_set_proc() variety.

I am not trying to hassle you; I know you don't have enough time to get through everything.  However, I'll hang fire on future development of stuff that I, personally, am not going to use, until I know when/if these patches are going to go in.
msg51519 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2007-01-29 19:30
The patch cannot go in in its current form (I started applying it, but then found that I just can't do it). It contains conditional, commented out code. Either the code is correct, then it should be added, or it is incorrect, in which case it should be removed entirely. There shouldn't be any work-in-progress code in the Python repository whatsoever. This refers to both the if 0 blocks (which I thought I can safely delete), as well as commented-out entries in CapabilityStateMethods (for which I didn't know what to do).

So while you are revising it, I have a few remarks:
- you can safely omit the generated configure changes from the patch - I will regenerate them, anyway.
- please follow the alphabet in the header files in (bsdtty.h < capabilities.h)
- please don't expose method on objects on which they aren't methods. E.g. cap_clear is available both as a method and a module-level function; that can't be both right (there should be one way to do it)
  Following the socket API, I think offering these as methods is reasonable
- try avoiding the extra copy in copy_ext (copying directly into the string). If you keep malloc calls, don't return NULL without setting a Python exception.
- use the "s" format for copy_int and from_text
- consider using booleans for [gs]et_flags
msg51520 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2007-01-30 04:52
ISTM that this would be better as a separate module or an optional submodule to posix.  The posix module is already 8720 lines.  I really don't want it to get bigger, especially when you realize how much #ifdef'ery is in there.  

Some other things I noticed:

You should use PyMem_Malloc instead of a raw malloc (same deal with free).  Methods that take no arguments should use METH_NOARGS and then there's no need to call PyArgs_ParseTuple (e.g., posix_cap_get_proc).  

There definitely shouldn't be any abort()s in there, even if #ifdef'ed out.

Is this 64-bit safe?  My manpage (gentoo) says this:  int  cap_set_flag(cap_t  cap_p,  cap_flag_t flag, int ncap, cap_value_t *caps, cap_flag_value_t value);

I see that you are using ints.  I don't know if that's correct on a 64-bit platform.  If not, you will need to modify the places that ints are used to take longs.

msg51521 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2007-02-10 19:56
I don't mind the POSIX module getting bigger. In C, these functions are all in a flat namespace, also. I like the view "if it's specified by POSIX, you find it in the POSIX module" (although this specific API was rejected for inclusion into POSIX). The functions are all very small, as the real functionality is in the C library, or even the OS kernel.

As for the ifdefery: most of it is straight-forward: functionality is either present or it isn't. It gets messy when it tries to use alternative underlying APIs, e.g. for Win32 or OS/2. If the code is to be refactored, this should be the way to go (i.e. move all Win32 and OS/2 implementations out of the module)

As for PyMem_Malloc: I see no need to use that API; it doesn't improve the code to do so, compared to malloc/free. All that matters it is symmetric.
msg68452 - (view) Author: Matt Kern (gj0aqzda) Date: 2008-06-20 11:33
Updated patch with numerous changes, which (hopefully) address the
issues you raised.
msg68454 - (view) Author: Matt Kern (gj0aqzda) Date: 2008-06-20 12:15
Updated patch with further documentation fixes.
msg68477 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-06-20 21:13
Unfortunately, these changes missed the beta for 2.6, so it must be
delayed until 2.7.
msg89339 - (view) Author: Matt Kern (gj0aqzda) Date: 2009-06-13 22:48
Ping.  Anything I can do?
msg110511 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-16 21:58
Matt Kern has put a lot of work into the attached patches from what I can see.  Common courtesy suggests that someone make an effort to review his work which now can only go into 3.2.  I would take it on myself but know nothing about POSIX and still find the Python C API intimidating.
msg136008 - (view) Author: Ross Lagerwall (rosslagerwall) (Python committer) Date: 2011-05-15 05:13
Adding this to the posix module would enforce linking with lcap and lattr always. The development headers for these are not installed by default on some distributions.

I think it would be better if they are added to a separate module (especially since all the functions are prefixed with cap_, it is like they are in their own namespace) which means that the module is optional for people that don't have/want to build the functionality.

What are your thoughts?
msg136031 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-05-15 15:07
posix module has many optional functions, which are available only on some systems.
msg136051 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-05-15 22:24
> The development headers for these are not installed by default on
> some distributions.

This is not an issue at all - that's what autoconf is for.

> Adding this to the posix module would enforce linking with lcap and
> lattr always.

That's a more serious problem, IMO; I think some people won't like the
additional dependency.

> I think it would be better if they are added to a separate module

Can you propose a name for the module?
msg136066 - (view) Author: Ross Lagerwall (rosslagerwall) (Python committer) Date: 2011-05-16 04:32
> > I think it would be better if they are added to a separate module

> Can you propose a name for the module?

I would say either posixcap or capabitilies.
msg136067 - (view) Author: Ross Lagerwall (rosslagerwall) (Python committer) Date: 2011-05-16 04:34
> I would say either posixcap or capabitilies.

The problem with capabilities is that it's easy to misspell, as I did :-)
msg136094 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-05-16 14:31
Another possibility is to make it a private module _posixcapabilities, which would be used in os module:

    from _posixcapabilities import *
except ImportError:
msg136097 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-16 14:38
"posixcap" sounds ok to me.
msg136127 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-05-16 21:07
> "posixcap" sounds ok to me.

Bike-sheddingly, it bothers me that these functions are actually
*not* defined by POSIX, but have been withdrawn before becoming
standard. So I'd rather call it linuxcap. Using _linuxcap, and
exposing them from os sounds fine to me.
Date User Action Args
2019-09-09 20:46:04nanjekyejoannahsetstage: needs patch -> patch review
pull_requests: + pull_request15463
2019-08-13 13:34:25nanjekyejoannahsetnosy: + nanjekyejoannah
2017-06-14 18:49:13Christian Hsetnosy: + Christian H
2014-05-13 22:12:23skrahsetnosy: - skrah
2014-04-28 23:30:35pitrousetstage: patch review -> needs patch
2014-02-03 19:54:14Arfreversetversions: + Python 3.5, - Python 3.3
2014-02-03 19:12:27BreamoreBoysetnosy: - BreamoreBoy
2012-05-16 15:57:21pitrousetnosy: + neologix
2011-05-16 21:07:50loewissetmessages: + msg136127
2011-05-16 14:38:46pitrousetmessages: + msg136097
2011-05-16 14:31:15Arfreversetmessages: + msg136094
2011-05-16 04:34:27rosslagerwallsetmessages: + msg136067
2011-05-16 04:32:49rosslagerwallsetmessages: + msg136066
2011-05-15 22:24:31loewissetmessages: + msg136051
2011-05-15 15:07:56Arfreversetmessages: + msg136031
2011-05-15 05:13:08rosslagerwallsetmessages: + msg136008
2011-01-17 13:35:02giampaolo.rodolasetnosy: + giampaolo.rodola

versions: + Python 3.3, - Python 3.2
2011-01-06 17:33:05pitrousetnosy: + rosslagerwall, pitrou
2010-07-16 22:21:38skrahsetnosy: + skrah
2010-07-16 21:58:09BreamoreBoysetnosy: + BreamoreBoy

messages: + msg110511
versions: - Python 2.7
2009-12-12 05:50:13ezio.melottisetkeywords: + needs review
2009-12-11 23:52:52Arfreversetnosy: + Arfrever

versions: + Python 3.2, - Python 3.1
2009-06-13 22:48:41gj0aqzdasetmessages: + msg89339
2009-03-30 18:02:17ajaksu2setstage: patch review
versions: + Python 3.1
2008-06-20 21:13:02loewissetmessages: + msg68477
versions: + Python 2.7, - Python 2.6
2008-06-20 12:15:48gj0aqzdasetfiles: + patch-20080620-1314.diff
messages: + msg68454
2008-06-20 11:34:08gj0aqzdasetfiles: + patch-20080620-1232.diff
messages: + msg68452
2008-01-05 20:05:39christian.heimessettype: enhancement
versions: + Python 2.6
2006-12-13 18:10:43gj0aqzdacreate