ericonr
/
util-linux
mirror of https://github.com/ericonr/util-linux.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
11,802 Commits 31 Branches 178 Tags 180 MiB
C 85.6%
Shell 9.2%
M4 1.9%
Meson 1.8%
Yacc 0.7%
Other 0.7%
Go to file
Patrick Steinhardt fbd15c4d47 setpriv: support setting unnamed capabilities 
When setting capabilities, we accept human readable names like for
example `sys_rawio` or `net_admin`. To do so the translation between the
capability name and its in-kernel index, we rely on the function
`capng_name_to_capability`. When the function does not know the named
capability, it will return an error value and we abort setting the
capability.

This relies upon the ability of libcap to know all capabilities inside
of the kernel. But actually, it is possible that new capabilities are
introduced inside of the Linux kernel which are not recognized yet by
the library. When dumping these unknown capabilities, libcap will simply
return a string like "cap_38", that is it will append the capability's
in-kernel index to the prefix "cap_". This may lead a user to also think
that "cap_38" may be passed to the switches "--inh-caps" or
"--ambient-caps", which is unfortunately not the case.

We can do better here by instead accepting strings in the form of
"cap_N". To do so, we can simply rely on the fact that capability
indices are steadily increasing and that the highest index known to the
kernel is stored inside of the kernel's procfs, made readily available
by our function `real_cap_last_cap()`. So in case libcap does not know a
capability name, we can simply parse the string and, if it is in the
correct format, check whether the detected index is between 0 and the
highest capability index. If so, we can treat it as a valid capability
string and apply it.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
 		2017-07-18 13:54:08 +02:00
Documentation docs: add optional option back to struct option 2017-07-15 22:05:00 +01:00
bash-completion bash-completion: make completions to work when bash set -u is in use 2017-07-15 22:05:42 +01:00
config
…
disk-utils cfdisk: use fdisk_reread_changes() 2017-07-14 11:34:55 +02:00
include partx: move partx.h to include/ 2017-07-14 11:34:55 +02:00
lib parse-date: fix printf format 2017-07-18 11:06:52 +02:00
libblkid build-sys: don't use non-existing UUID_LIBS 2017-07-18 11:06:53 +02:00
libfdisk libfdisk: fix warning -Wunused-function 2017-07-18 11:08:28 +02:00
libmount build-sys: don't use non-existing UUID_LIBS 2017-07-18 11:06:53 +02:00
libsmartcols misc: never use usage(stderr) 2017-06-26 14:38:24 +02:00
libuuid build-sys: fix library order when linking 2017-06-01 03:16:48 +02:00
login-utils Merge branch 'help' of https://github.com/rudimeier/util-linux 2017-07-10 10:15:22 +02:00
m4 build-sys: prefer ncurses-config rather than pkg-config 2017-05-31 10:54:21 +02:00
misc-utils misc: consolidate macro style USAGE_HELP_OPTIONS 2017-06-29 16:54:33 +02:00
po po: merge changes 2017-06-02 11:30:19 +02:00
schedutils misc: consolidate macro style USAGE_HELP_OPTIONS 2017-06-29 16:54:33 +02:00
sys-utils setpriv: support setting unnamed capabilities 2017-07-18 13:54:08 +02:00
term-utils reset: remove script from the package 2017-07-15 22:02:53 +01:00
tests tests: remove UUIDs with time overflow from uuidparse 2017-07-18 10:01:22 +02:00
text-utils misc: consolidate macro style USAGE_HELP_OPTIONS 2017-06-29 16:54:33 +02:00
tools tools: add segfault detection for checkusage.sh 2017-06-29 14:04:29 +02:00
.editorconfig add .editorconfig 2016-01-25 00:12:14 +01:00
.gitignore uuidparse: add new command 2017-06-26 14:46:35 +02:00
.travis-functions.sh travis: add make checkusage 2017-06-27 08:25:30 +02:00
.travis.yml travis: minor cosmetics 2017-06-15 09:13:14 +02:00
AUTHORS docs: update AUTHORS file 2017-06-02 12:16:08 +02:00
COPYING
…
ChangeLog
…
Makefile.am build-sys: fix chown mistake, add checkusage.sh to the dist 2017-06-26 21:00:09 +02:00
NEWS build-sys: release++ (v2.30) 2017-06-02 12:22:29 +02:00
README docs: add information about mailing list rejection 2017-06-01 19:42:21 -04:00
README.licensing COPYING: fix grammar of referring phrase, and indicate location better 2013-10-08 15:38:39 +02:00
autogen.sh build-sys: add parse-date.y 2017-03-04 11:01:56 -05:00
configure.ac ldattach: simplify debugging function when vwarnx(3) is available 2017-07-15 22:02:53 +01:00
util-linux.doap docs: replace FTP by HTTPS in kernel.org URLs 2016-12-19 11:22:26 +01:00

README 

				  util-linux

		util-linux is a random collection of Linux utilities

     Note: for the years 2006-2010 this project was named "util-linux-ng".

MAILING LIST:

      E-MAIL: util-linux@vger.kernel.org
      URL:    http://vger.kernel.org/vger-lists.html#util-linux

      The mailing list will reject email messages that contain:
       - more than 100K characters
       - html
       - spam phrases/keywords
      See: http://vger.kernel.org/majordomo-info.html#taboo

IRC CHANNEL:

      #util-linux at freenode.net:

      irc://chat.freenode.net/util-linux

      The IRC channel and Mailing list are for developers and project
      maintainers. For end users it is recommended to utilize the
      distribution's support system.

BUG REPORTING:

      E-MAIL: util-linux@vger.kernel.org
      Web:    https://github.com/karelzak/util-linux/issues

      This project has no resources to provide support for distribution specific
      issues. For end users it is recommended to utilize the distribution's
      support system.

NLS (PO TRANSLATIONS):

      PO files are maintained by:
	  http://translationproject.org/domain/util-linux.html

VERSION SCHEMA:

      Standard releases:
	  <major>.<minor>[.<maint>]
	     major = fatal and deep changes
	     minor = typical release with new features
	     maint = maintenance releases; bug fixes only

      Development releases:
	 <major>.<minor>-rc<N>

SOURCE CODE:

 Download archive:
	  https://www.kernel.org/pub/linux/utils/util-linux/

 SCM (Source Code Management) Repository:

    Primary repository:
	  git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git

    Backup repository:
	  git clone git://github.com/karelzak/util-linux.git

    Web interfaces:
	  http://git.kernel.org/cgit/utils/util-linux/util-linux.git
	  https://github.com/karelzak/util-linux

      Note: the GitHub repository may contain temporary development branches too.

      The kernel.org repository contains master (current development) and stable/*
      (maintenance) branches only. All master or stable/* changes are always pushed
      to both repositories at the same time.

    Repository Branches: 'git branch -a'
	  master branch
	   - current development
	   - the source for stable releases when deemed ready.
	   - day-to-day status is: 'it works for me'. This means that its
	     normal state is useful but not well tested.
	   - long-term development or invasive changes in active development are
	     forked into separate 'topic' branches from the tip of 'master'.

	  stable/ branches
	   - public releases
	   - branch name: stable/v<major>.<minor>.
	   - created from the 'master' branch after two or more release
	     candidates and the final public release. This means that the stable
	     releases are committed, tagged, and reachable in 'master'.
	   - these branches then become forked development branches. This means
	     that any changes made to them diverge from the 'master' branch.
	   - maintenance releases are part of, and belong to, their respective
	     stable branch. As such, they are tags(<major>.<minor>.<maint>) and
	     not branches of their own. They are not part of, visible in, or
	     have anything to do with the 'master' development branch. In git
	     terminology: maintenance releases are not reachable from 'master'.
	   - when initially cloned (as with the 'git clone' command given above)
	     these branches are created as 'remote tracking branches' and are
	     only visible by using the -a or -r options to 'git branch'. To
	     create a local branch use the desired tag with this command:
	     'git checkout -b v2.29.2 v2.29.2'

    Tags: 'git tag'
	   - a new tag object is created for every release.
	   - tag name: v<version>.
	   - all tags are signed by the maintainer's PGP key.

    Known Bugs:
	- don't use tag v2.13.1 (created and published by mistake),
	  use v2.13.1-REAL instead.

WORKFLOW EXAMPLE:

 1) development (branch: <master>)

 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)

 3) development (work on v2.30, branch: <master>)

 4) fork -- create a new branch <stable/v2.29> based on tag v2.29

     4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>)

     4b) stable release (tag: v2.29.1, branch: <stable/v2.29>)

     4c) more patches; another release (tag: v2.29.2, branch: <stable/v2.29>)

 5) master release v2.30 (branch: <master>)
    ...

where 3) and 4) happen simultaneously.