提交 · 1fd36adcd98c14d2fd97f545293c488775cb2823 · OpenHarmony / kernel_linux

20 2月, 2012 1 次提交

Replace the fd_sets in struct fdtable with an array of unsigned longs · 1fd36adc

由 David Howells 提交于 2月 16, 2012

Replace the fd_sets in struct fdtable with an array of unsigned longs and then
use the standard non-atomic bit operations rather than the FD_* macros.

This:

 (1) Removes the abuses of struct fd_set:

     (a) Since we don't want to allocate a full fd_set the vast majority of the
     	 time, we actually, in effect, just allocate a just-big-enough array of
     	 unsigned longs and cast it to an fd_set type - so why bother with the
     	 fd_set at all?

     (b) Some places outside of the core fdtable handling code (such as
     	 SELinux) want to look inside the array of unsigned longs hidden inside
     	 the fd_set struct for more efficient iteration over the entire set.

 (2) Eliminates the use of FD_*() macros in the kernel completely.

 (3) Permits the __FD_*() macros to be deleted entirely where not exposed to
     userspace.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Link: http://lkml.kernel.org/r/20120216174954.23314.48147.stgit@warthog.procyon.org.ukSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>

1fd36adc

07 1月, 2012 1 次提交
- A
  vfs: prefer ->dentry->d_sb to ->mnt->mnt_sb · d8c9584e
  由 Al Viro 提交于 12月 07, 2011
```
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
```
  d8c9584e
06 1月, 2012 9 次提交

security: remove the security_netlink_recv hook as it is equivalent to capable() · fd778461

由 Eric Paris 提交于 1月 03, 2012

Once upon a time netlink was not sync and we had to get the effective
capabilities from the skb that was being received.  Today we instead get
the capabilities from the current task.  This has rendered the entire
purpose of the hook moot as it is now functionally equivalent to the
capable() call.
Signed-off-by: NEric Paris <eparis@redhat.com>

fd778461

ptrace: do not audit capability check when outputing /proc/pid/stat · 69f594a3

由 Eric Paris 提交于 1月 03, 2012

Reading /proc/pid/stat of another process checks if one has ptrace permissions
on that process. If one does have permissions it outputs some data about the
process which might have security and attack implications. If the current
task does not have ptrace permissions the read still works, but those fields
are filled with inocuous (0) values. Since this check and a subsequent denial
is not a violation of the security policy we should not audit such denials.

This can be quite useful to removing ptrace broadly across a system without
flooding the logs when ps is run or something which harmlessly walks proc.
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: NSerge E. Hallyn <serge.hallyn@canonical.com>

69f594a3

capabilities: remove the task from capable LSM hook entirely · 6a9de491

由 Eric Paris 提交于 1月 03, 2012

The capabilities framework is based around credentials, not necessarily the
current task. Yet we still passed the current task down into LSMs from the
security_capable() LSM hook as if it was a meaningful portion of the security
decision. This patch removes the 'generic' passing of current and instead
forces individual LSMs to use current explicitly if they think it is
appropriate. In our case those LSMs are SELinux and AppArmor.

I believe the AppArmor use of current is incorrect, but that is wholely
unrelated to this patch. This patch does not change what AppArmor does, it
just makes it clear in the AppArmor code that it is doing it.

The SELinux code still uses current in it's audit message, which may also be
wrong and needs further investigation. Again this is NOT a change, it may
have always been wrong, this patch just makes it clear what is happening.
Signed-off-by: NEric Paris <eparis@redhat.com>

6a9de491

selinux: sparse fix: fix several warnings in the security server cod · 2653812e