serge.hallyn | 22 Apr 19:26 2016

namespaced file capabilities

Hi,

I've sent a few patches and emails over the past months about supporting
file capabilities in user namespace confined containers.  A few of the
requirements as I see them are:

1. Root in a user namespace should be able to set file capabilities on a binary
for use by any user mapped into his namespace.

2. Any uid not mapped into the user namespace whose root user set file
capabilities should not gain privileges when running an executable which only
has file capabilities set by this root user.

3. Existing calls to cap_set_file(3) and cap_get_file(3) as well as
setcap(8) and getcap(8) should transparently work.  This would allow
package managers to simply set file capabilities in postinst.

Below is a kernel patch which implements a new security.nscapability
extended attribute.  Setting this xattr on a file requires cap_setfcap
against the current user namespace, and for the file to be owned by
a uid and gid mapped into that namespace.  When found on a file,
the capabilities will take effect only if the file is owned by the
root uid in the caller's namespace, or the root uid in any ancestor
namespace.

While this design supports nested namespaces, it does not support
use of file capabilities by users in unrelated namespaces.  So if
the same file is linked into two namespaces N1 and N2 which do not
share the same root kuid, then the only way for N1 and N2 to both
execute the file while respecting security.nscapability is to have
(Continue reading)

andreas122 | 18 Apr 22:12 2016

Greetings!!!

Hi, how are you? My name is J Eric Denials, External Financial Auditor at Lloyds Banking Group plc., London.
It is a pleasure to contact you at this time through this medium. I have a cool and legitimate deal to do with
you as you're a foreigner, it will be mutually beneficial to both. If you’re interested, urgently, get
back to me for more explanation about the deal.
Regards
Eric
andreas11 | 18 Apr 19:43 2016

Greetings!!!

Hi, how are you? My name is J Eric Denials, External Financial Auditor at Lloyds Banking Group plc., London.
It is a pleasure to contact you at this time through this medium. I have a cool and legitimate deal to do with
you as you're a foreigner, it will be mutually beneficial to both. If you’re interested, urgently, get
back to me for more explanation about the deal.
Regards
Eric
Tadeusz Struk | 15 Apr 22:22 2016
Picon

[PATCH v5 0/6] crypto: algif - add akcipher

First four patches are a resend of the v3 algif_akcipher from
Stephan Mueller, with minor changes after rebase on top of 4.6-rc1.

The next three patches add support for keys stored in system
keyring subsystem.

First patch adds algif_akcipher nokey hadlers.

Second patch adds generic sign, verify, encrypt, decrypt accessors
functions to the asymmetric key type. These will be defined by
asymmetric subtypes, similarly to how public_key currently defines
the verify_signature function. 

Third patch adds support for ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID
commands to AF_ALG and setkeyid operation to the af_alg_type struct.
If the keyid is used then the afalg layer acquires the key for the
keyring subsystem and uses the new asymmetric accessor functions
instead of akcipher api. The asymmetric subtypes can use akcipher
api internally.

Patches generated on top of 
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-next
plus this:
https://patchwork.kernel.org/patch/8843381/

v5 changes:
- drop public key changes and use new version provided by David
- rebase on key-next and https://patchwork.kernel.org/patch/8843381/

v4 changes:
(Continue reading)

Petr Mladek | 14 Apr 17:14 2016
Gravatar

[PATCH v6 00/20] kthread: Use kthread worker API more widely

My intention is to make it easier to manipulate and maintain kthreads.
Especially, I want to replace all the custom main cycles with a
generic one. Also I want to make the kthreads sleep in a consistent
state in a common place when there is no work.

My first attempt was with a brand new API (iterant kthread), see
http://thread.gmane.org/gmane.linux.kernel.api/11892 . But I was
directed to improve the existing kthread worker API. This is
the 4th iteration of the new direction.

1nd..10th patches: improve the existing kthread worker API

11th..16th, 18th, 20th patches: convert several kthreads into
      the kthread worker API, namely: khugepaged, ring buffer
      benchmark, hung_task, kmemleak, ipmi, IB/fmr_pool,
      memstick/r592, intel_powerclamp

17th, 19th patches: do some preparation steps; they usually do
      some clean up that makes sense even without the conversion.

Changes against v5:

  + removed spin_trylock() from delayed_kthread_work_timer_fn();
    instead temporary released worked->lock() when calling
    del_timer_sync(); made sure that any queueing was blocked
    by work->canceling in the meatime

  + used 0th byte for KTW_FREEZABLE to reduce confusion

  + fixed warnings in comments reported by make htmldocs
(Continue reading)

Richard W.M. Jones | 13 Apr 21:05 2016
Picon
Gravatar

[PATCH v4 0/3] vfs: Define new syscall umask2 [formerly getumask]

v3 -> v4:

 - Rename the syscall: getumask becomes umask2.

 - Add flags parameter, with one flag (UMASK_GET_MASK).

 - Expand the rationale for this change in the first commit message.

 - Add a selftest.

 - Retest everything.

--------------------

It's not possible to read the process umask without also modifying it,
which is what umask(2) does.  A library cannot read umask safely,
especially if the main program might be multithreaded.

This patch series adds a new system call "umask2".  This adds a flags
parameter.  Specifying flags=UMASK_GET_MASK allows the umask of the
current process to be read without modifying it.

This leaves open the possibility in future of adding a per-thread
umask, set or read with other flags.  This is not implemented.

Another approach to this has been attempted before, adding something
to /proc, although it didn't go anywhere.  See:

  http://comments.gmane.org/gmane.linux.kernel/1292109

(Continue reading)

Richard W.M. Jones | 13 Apr 14:57 2016
Picon
Gravatar

[PATCH v2 0/2] vfs: Define new syscall getumask.

v1 -> v2:

 - Use current_umask() instead of current->fs->umask.

 - Retested it.

----------------------------------------------------------------------

It's not possible to read the process umask without also modifying it,
which is what umask(2) does.  A library cannot read umask safely,
especially if the main program might be multithreaded.

This patch series adds a trivial system call "getumask" which returns
the umask of the current process.

Another approach to this has been attempted before, adding something
to /proc, although it didn't go anywhere.  See:

  http://comments.gmane.org/gmane.linux.kernel/1292109

Another way to solve this would be to add a thread-safe getumask to
glibc.  Since glibc could own the mutex, this would permit libraries
linked to this glibc to read umask safely.

I should also note that man-pages documents getumask(3), but no
version of glibc has ever implemented it.

Typical test script:

#include <stdio.h>
(Continue reading)

Richard W.M. Jones | 13 Apr 13:43 2016
Picon
Gravatar

[PATCH 0/2] vfs: Define new syscall getumask.

It's not possible to read the process umask without also modifying it,
which is what umask(2) does.  A library cannot read umask safely,
especially if the main program might be multithreaded.

This patch series adds a trivial system call "getumask" which returns
the umask of the current process.

Another approach to this has been attempted before, adding something
to /proc, although it didn't go anywhere.  See:

  http://comments.gmane.org/gmane.linux.kernel/1292109

Another way to solve this would be to add a thread-safe getumask to
glibc.  Since glibc could own the mutex, this would permit libraries
linked to this glibc to read umask safely.

I should also note that man-pages documents getumask(3), but no
version of glibc has ever implemented it.

Typical test script:

#include <stdio.h>
#include <stdlib.h>
#include <linux/unistd.h>
#include <sys/syscall.h>

int main(int argc, char *argv[])
{
  int r = syscall(329);
  if (r == -1) {
(Continue reading)

Darrick J. Wong | 13 Apr 06:01 2016
Picon

[RFC DONOTMERGE v8 0/3] fallocate for block devices

Hi,

This is a redesign of the patch series that fixes various interface
problems with the existing "zero out this part of a block device"
code.  BLKZEROOUT2 is gone.

The first patch is still a fix to the existing BLKZEROOUT ioctl to
invalidate the page cache if the zeroing command to the underlying
device succeeds.

The second patch changes the internal block device functions to reject
attempts to discard or zeroout that are not aligned to the logical
block size.  Previously, we only checked that the start/len parameters
were 512-byte aligned, which caused kernel BUG_ONs for unaligned IOs
to 4k-LBA devices.

The third patch creates an fallocate handler for block devices, wires
up the FALLOC_FL_PUNCH_HOLE flag to zeroing-discard, and connects
FALLOC_FL_ZERO_RANGE to write-same so that we can have a consistent
fallocate interface between files and block devices.  It also allows
the combination of PUNCH_HOLE and NO_HIDE_STALE to invoke non-zeroing
discard.

The point of this patchset is not to go upstream, but is to be a
starting point for a discussion at LSF.  Don't merge this!  Foremost
in my mind is whether or not we require the offset/len parameters to
be aligned to logical block size or minimum_io_size; what error code
to return for unaligned values; and whether or not we should allow
byte ranges and zero blocks with the page cache (like file fallocate
does now).  It'll also be a jumping off point for Brian Foster and
(Continue reading)

Stas Sergeev | 9 Apr 14:42 2016
Picon

[PATCH v6(RESEND) 0/4] make sigaltstack() compatible with swapcontext()

It is absolutely unclear what happened with my patch series,
but it is neither applied nor rejected. So here's the re-send.

The following patches make it possible to use swapcontext()
in a sighandler that works on sigaltstack.
The approach is inspired by Andy Lutomirski's suggestion that
sigaltstack should disarm itself after saving into uc_stack:
https://lkml.org/lkml/2016/2/1/594

I add the SS_AUTODISARM flag that does exactly that.
On sighandler exit, the sigaltstack is restored from uc_stack.
Another possible name could be SS_ONESHOT, but, since it gets
always re-enabled, I choose SS_AUTODISARM.

Change since v5:
- Fix description of patch 4/4

Change since v4:
- Implement this Andy Lutomirski's suggestion:
https://lkml.org/lkml/2016/3/6/158
that allows the run-time probing of the existence of the
flags added in the future.

[PATCH 1/4] [Cleanup] x86: signal: unify the sigaltstack check with
	A clean-up patch that unifies x86's sigaltstack handling with
	other arches.
[PATCH 2/4] sigaltstack: preparations for adding new SS_xxx flags
	Andy's suggested changes
[PATCH 3/4] sigaltstack: implement SS_AUTODISARM flag
	This patch implements SS_AUTODISARM flag
(Continue reading)

Christoph Hellwig | 7 Apr 17:51 2016
Picon

add RWF_(D)SYNC flag to preadv2/pwritev2 V2

Add per-I/O sync flags, which are very useful for all kinds of file servers
or storage targets.  To properly do this refactor lots of direct I/O code
to not pass pointless argument, which makes the whole series a net negative
in terms of lines of code.

Changes since V1:
 - fix RWF_SYNC defintion
 - fix a comment


Gmane