The permissions of files in /proc/1 (usually belonging to init) are
kept as they are. The idea is to let system processes be freely
visible by anyone, just as before. Especially interesting in this
regard would be instances of login. I don't know how to easily
discriminate between system
>> The permissions of files in /proc/1 (usually belonging to init) are
>> kept as they are. The idea is to let system processes be freely
>> visible by anyone, just as before. Especially interesting in this
>> regard would be instances of login. I don't know how t
The following patches implement another interface that allows an admin
to restrict permissions inside /proc/pid to enhance the privacy of
users. Following a suggestion by Albert Calahan this set of patches
introduces five sysctls, each one changes the permissions of a certain
file in /proc/pid
The following patches implement another interface that allows an admin
to restrict permissions inside /proc/ to enhance the privacy of
users. Following a suggestion by Albert Calahan this set of patches
introduces five sysctls, each one changes the permissions of a certain
file in /proc
commit 2732587540035227fe59e4b64b60127352611b35
Author: Lucas Werkmeister
Date: Wed Jan 16 00:16:10 2019 +0100
Enable regular file and FIFO protection
These sysctls were added in Linux 4.19 (torvalds/linux@30aba6656f), and
we should enable them just like we enable the older ha
On Sun, 2005-03-20 at 01:22 +0100, Rene Scharfe wrote:
The permissions of files in /proc/1 (usually belonging to init) are
kept as they are. The idea is to let system processes be freely
visible by anyone, just as before. Especially interesting in this
regard would be instances of login. I
On Sun, 2005-03-20 at 01:22 +0100, Rene Scharfe wrote:
> The permissions of files in /proc/1 (usually belonging to init) are
> kept as they are. The idea is to let system processes be freely
> visible by anyone, just as before. Especially interesting in this
> regard would be instan
the settings cannot change. And we
don't need the added flexibility of sysctls anyway -- I assume these
parameters are set at installation time and never touched again.
This means mucking with boot parameters, which can be a pain.
The various boot loaders do not all use the same config file.
Then I
lementation a lot because we know the settings cannot change. And we
> don't need the added flexibility of sysctls anyway -- I assume these
> parameters are set at installation time and never touched again.
This means mucking with boot parameters, which can be a pain.
The various boot loaders d
rom 0 - ULLONG_MAX
An application setting the value must have PTRACE_MODE_ATTACH_FSCREDS level
permissions on the task specified to change its timerslack_ns value.
+3.11 /proc//userns_counts - User namespace counters
+-
+
+This file provides cur
PTRACE_MODE_ATTACH_FSCREDS level
permissions on the task specified to change its timerslack_ns value.
+3.11 /proc//userns_counts - User namespace counters
+-
+
+This file provides current usage of user namespace counters.
+
+User namespace counters
On Sun, 20 Mar 2005, Rene Scharfe wrote:
The permissions of files in /proc/1 (usually belonging to init) are
kept as they are. The idea is to let system processes be freely
visible by anyone, just as before. Especially interesting in this
regard would be instances of login.
I think you
On Sun, 20 Mar 2005, Rene Scharfe wrote:
> The permissions of files in /proc/1 (usually belonging to init) are
> kept as they are. The idea is to let system processes be freely
> visible by anyone, just as before. Especially interesting in this
> regard would be instances of login.
implementation a lot because we know the settings cannot change. And we
don't need the added flexibility of sysctls anyway -- I assume these
parameters are set at installation time and never touched again.
Then I suppose we don't need to be able to fine-tune the permissions for
each file in /proc
sufficient. It simplifies
implementation a lot because we know the settings cannot change. And we
don't need the added flexibility of sysctls anyway -- I assume these
parameters are set at installation time and never touched again.
Then I suppose we don't need to be able to fine-tune the permissions for
-1,13 +1,14 @@
+
+Yama
+
+
Yama is a Linux Security Module that collects system-wide DAC security
protections that are not handled by the core kernel itself. This is
-selectable at build-time with CONFIG_SECURITY_YAMA, and can be controlled
-at run-time through sysctls in /proc/sys
+Yama
+
+
Yama is a Linux Security Module that collects system-wide DAC security
protections that are not handled by the core kernel itself. This is
-selectable at build-time with CONFIG_SECURITY_YAMA, and can be controlled
-at run-time through sysctls in /proc/sys/kernel/yama:
-
-- ptrace_scope
+sele
applications to depend on what those attribute are set to
> and even when the different entities do different things, the
> combination is still something coherent.
>
> Now, if you make the in-process grouping dynamic and accessible to
> external entities (and if we aren't gonna do t
attribute are set to
> and even when the different entities do different things, the
> combination is still something coherent.
>
> Now, if you make the in-process grouping dynamic and accessible to
> external entities (and if we aren't gonna do that, why even bother?),
> this bre
ontent): Merge conflict in fs/afs/security.c
$ git rm -f fs/crypto/keyinfo.c
Applying: fsverity: merge fix for keyring_alloc API change
Applying: fscrypt: merge resolution for "keys: Replace uid/gid/perm permissions
checking with an ACL"
Applying: dm verity: merge fix for "keys
crypto/keyinfo.c left in tree.
CONFLICT (content): Merge conflict in fs/afs/security.c
$ git rm -f fs/crypto/keyinfo.c
Applying: fsverity: merge fix for keyring_alloc API change
Applying: fscrypt: merge resolution for "keys: Replace uid/gid/perm permissions
checking with an ACL"
Applying
.
[SPARC64]: Fix floppy build failure.
[NET]: Revert incorrect accept queue backlog changes.
David Stevens (1):
[IPV6]: /proc/net/anycast6 unbalanced inet6_dev refcnt
Dimitri Gorokhovik (1):
initramfs should not depend on CONFIG_BLOCK
Dirk Behme (8):
ARM: OMAP: Fix warning
PARC64]: Fix floppy build failure.
[NET]: Revert incorrect accept queue backlog changes.
David Stevens (1):
[IPV6]: /proc/net/anycast6 unbalanced inet6_dev refcnt
Dimitri Gorokhovik (1):
initramfs should not depend on CONFIG_BLOCK
Dirk Behme (8):
ARM: OMAP: Fix warning in clock.c
23 matches
Mail list logo
