- 28 7月, 2014 1 次提交
-
-
由 Paul Moore 提交于
This reverts commit 4da6daf4. Unfortunately, the commit in question caused problems with Bluetooth devices, specifically it caused them to get caught in the newly created BUG_ON() check. The AF_ALG problem still exists, but will be addressed in a future patch. Cc: stable@vger.kernel.org Signed-off-by: NPaul Moore <pmoore@redhat.com>
-
- 26 7月, 2014 1 次提交
-
-
由 Kees Cook 提交于
In order to validate the contents of firmware being loaded, there must be a hook to evaluate any loaded firmware that wasn't built into the kernel itself. Without this, there is a risk that a root user could load malicious firmware designed to mount an attack against kernel memory (e.g. via DMA). Signed-off-by: NKees Cook <keescook@chromium.org> Reviewed-by: NTakashi Iwai <tiwai@suse.de>
-
- 10 7月, 2014 1 次提交
-
-
由 Paul Moore 提交于
The sock_graft() hook has special handling for AF_INET, AF_INET, and AF_UNIX sockets as those address families have special hooks which label the sock before it is attached its associated socket. Unfortunately, the sock_graft() hook was missing a default approach to labeling sockets which meant that any other address family which made use of connections or the accept() syscall would find the returned socket to be in an "unlabeled" state. This was recently demonstrated by the kcrypto/AF_ALG subsystem and the newly released cryptsetup package (cryptsetup v1.6.5 and later). This patch preserves the special handling in selinux_sock_graft(), but adds a default behavior - setting the sock's label equal to the associated socket - which resolves the problem with AF_ALG and presumably any other address family which makes use of accept(). Cc: stable@vger.kernel.org Signed-off-by: NPaul Moore <pmoore@redhat.com> Tested-by: NMilan Broz <gmazyland@gmail.com>
-
- 01 4月, 2014 1 次提交
-
-
由 Miklos Szeredi 提交于
Add flags to security_path_rename() and security_inode_rename() hooks. Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz> Reviewed-by: NJ. Bruce Fields <bfields@redhat.com>
-
- 15 3月, 2014 1 次提交
-
-
由 David Howells 提交于
Move the flags representing required permission to linux/key.h as the perm parameter of security_key_permission() is in terms of them - and not the permissions mask flags used in key->perm. Whilst we're at it: (1) Rename them to be KEY_NEED_xxx rather than KEY_xxx to avoid collisions with symbols in uapi/linux/input.h. (2) Don't use key_perm_t for a mask of required permissions, but rather limit it to the permissions mask attached to the key and arguments related directly to that. Signed-off-by: NDavid Howells <dhowells@redhat.com> Tested-by: NDmitry Kasatkin <d.kasatkin@samsung.com>
-
- 10 3月, 2014 1 次提交
-
-
由 Nikolay Aleksandrov 提交于
security_xfrm_policy_alloc can be called in atomic context so the allocation should be done with GFP_ATOMIC. Add an argument to let the callers choose the appropriate way. In order to do so a gfp argument needs to be added to the method xfrm_policy_alloc_security in struct security_operations and to the internal function selinux_xfrm_alloc_user. After that switch to GFP_ATOMIC in the atomic callers and leave GFP_KERNEL as before for the rest. The path that needed the gfp argument addition is: security_xfrm_policy_alloc -> security_ops.xfrm_policy_alloc_security -> all users of xfrm_policy_alloc_security (e.g. selinux_xfrm_policy_alloc) -> selinux_xfrm_alloc_user (here the allocation used to be GFP_KERNEL only) Now adding a gfp argument to selinux_xfrm_alloc_user requires us to also add it to security_context_to_sid which is used inside and prior to this patch did only GFP_KERNEL allocation. So add gfp argument to security_context_to_sid and adjust all of its callers as well. CC: Paul Moore <paul@paul-moore.com> CC: Dave Jones <davej@redhat.com> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Fan Du <fan.du@windriver.com> CC: David S. Miller <davem@davemloft.net> CC: LSM list <linux-security-module@vger.kernel.org> CC: SELinux list <selinux@tycho.nsa.gov> Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com> Acked-by: NPaul Moore <paul@paul-moore.com> Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
-
- 26 7月, 2013 1 次提交
-
-
由 Paul Moore 提交于
The xfrm_state_alloc_security() LSM hook implementation is really a multiplexed hook with two different behaviors depending on the arguments passed to it by the caller. This patch splits the LSM hook implementation into two new hook implementations, which match the LSM hooks in the rest of the kernel: * xfrm_state_alloc * xfrm_state_alloc_acquire Also included in this patch are the necessary changes to the SELinux code; no other LSMs are affected. Signed-off-by: NPaul Moore <pmoore@redhat.com> Signed-off-by: NEric Paris <eparis@redhat.com>
-
- 25 7月, 2013 1 次提交
-
-
由 Tetsuo Handa 提交于
Since everybody sets kstrdup()ed constant string to "struct xattr"->name but nobody modifies "struct xattr"->name , we can omit kstrdup() and its failure checking by constifying ->name member of "struct xattr". Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Joel Becker <jlbec@evilplan.org> [ocfs2] Acked-by: NSerge E. Hallyn <serge.hallyn@ubuntu.com> Acked-by: NCasey Schaufler <casey@schaufler-ca.com> Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com> Reviewed-by: NPaul Moore <paul@paul-moore.com> Tested-by: NPaul Moore <paul@paul-moore.com> Acked-by: NEric Paris <eparis@redhat.com> Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 09 6月, 2013 4 次提交
-
-
由 David Quigley 提交于
There currently doesn't exist a labeling type that is adequate for use with labeled NFS. Since NFS doesn't really support xattrs we can't use the use xattr labeling behavior. For this we developed a new labeling type. The native labeling type is used solely by NFS to ensure NFS inodes are labeled at runtime by the NFS code instead of relying on the SELinux security server on the client end. Acked-by: NEric Paris <eparis@redhat.com> Acked-by: NJames Morris <james.l.morris@oracle.com> Signed-off-by: NMatthew N. Dodd <Matthew.Dodd@sparta.com> Signed-off-by: NMiguel Rodel Felipe <Rodel_FM@dsi.a-star.edu.sg> Signed-off-by: NPhua Eu Gene <PHUA_Eu_Gene@dsi.a-star.edu.sg> Signed-off-by: NKhin Mi Mi Aung <Mi_Mi_AUNG@dsi.a-star.edu.sg> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
由 David Quigley 提交于
There is no way to differentiate if a text mount option is passed from user space or the kernel. A flags field is being added to the security_sb_set_mnt_opts hook to allow for in kernel security flags to be sent to the LSM for processing in addition to the text options received from mount. This patch also updated existing code to fix compilation errors. Acked-by: NEric Paris <eparis@redhat.com> Acked-by: NJames Morris <james.l.morris@oracle.com> Signed-off-by: NDavid P. Quigley <dpquigl@tycho.nsa.gov> Signed-off-by: NMiguel Rodel Felipe <Rodel_FM@dsi.a-star.edu.sg> Signed-off-by: NPhua Eu Gene <PHUA_Eu_Gene@dsi.a-star.edu.sg> Signed-off-by: NKhin Mi Mi Aung <Mi_Mi_AUNG@dsi.a-star.edu.sg> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
由 David Quigley 提交于
The interface to request security labels from user space is the xattr interface. When requesting the security label from an NFS server it is important to make sure the requested xattr actually is a MAC label. This allows us to make sure that we get the desired semantics from the attribute instead of something else such as capabilities or a time based LSM. Acked-by: NEric Paris <eparis@redhat.com> Acked-by: NJames Morris <james.l.morris@oracle.com> Signed-off-by: NMatthew N. Dodd <Matthew.Dodd@sparta.com> Signed-off-by: NMiguel Rodel Felipe <Rodel_FM@dsi.a-star.edu.sg> Signed-off-by: NPhua Eu Gene <PHUA_Eu_Gene@dsi.a-star.edu.sg> Signed-off-by: NKhin Mi Mi Aung <Mi_Mi_AUNG@dsi.a-star.edu.sg> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
由 David Quigley 提交于
There is a time where we need to calculate a context without the inode having been created yet. To do this we take the negative dentry and calculate a context based on the process and the parent directory contexts. Acked-by: NEric Paris <eparis@redhat.com> Acked-by: NJames Morris <james.l.morris@oracle.com> Signed-off-by: NMatthew N. Dodd <Matthew.Dodd@sparta.com> Signed-off-by: NMiguel Rodel Felipe <Rodel_FM@dsi.a-star.edu.sg> Signed-off-by: NPhua Eu Gene <PHUA_Eu_Gene@dsi.a-star.edu.sg> Signed-off-by: NKhin Mi Mi Aung <Mi_Mi_AUNG@dsi.a-star.edu.sg> Signed-off-by: NSteve Dickson <steved@redhat.com> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
-
- 12 5月, 2013 1 次提交
-
-
由 J. Bruce Fields 提交于
Make it clear that cap_inode_getsecctx shouldn't return success without filling in the context data. Acked-by: NSerge E. Hallyn <serge.hallyn@ubuntu.com> Signed-off-by: NJ. Bruce Fields <bfields@redhat.com> Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 11 4月, 2013 1 次提交
-
-
由 Paul Moore 提交于
Unfortunately we didn't catch the missing comments earlier when the patch was merged. Signed-off-by: NPaul Moore <pmoore@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 10 4月, 2013 1 次提交
-
-
由 Eric Dumazet 提交于
Commit 90ba9b19 (tcp: tcp_make_synack() can use alloc_skb()) broke certain SELinux/NetLabel configurations by no longer correctly assigning the sock to the outgoing SYNACK packet. Cost of atomic operations on the LISTEN socket is quite big, and we would like it to happen only if really needed. This patch introduces a new security_ops->skb_owned_by() method, that is a void operation unless selinux is active. Reported-by: NMiroslav Vadkerti <mvadkert@redhat.com> Diagnosed-by: NPaul Moore <pmoore@redhat.com> Signed-off-by: NEric Dumazet <edumazet@google.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-security-module@vger.kernel.org Acked-by: NJames Morris <james.l.morris@oracle.com> Tested-by: NPaul Moore <pmoore@redhat.com> Acked-by: NPaul Moore <pmoore@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 02 4月, 2013 1 次提交
-
-
由 Jeff Layton 提交于
I had the following problem reported a while back. If you mount the same filesystem twice using NFSv4 with different contexts, then the second context= option is ignored. For instance: # mount server:/export /mnt/test1 # mount server:/export /mnt/test2 -o context=system_u:object_r:tmp_t:s0 # ls -dZ /mnt/test1 drwxrwxrwt. root root system_u:object_r:nfs_t:s0 /mnt/test1 # ls -dZ /mnt/test2 drwxrwxrwt. root root system_u:object_r:nfs_t:s0 /mnt/test2 When we call into SELinux to set the context of a "cloned" superblock, it will currently just bail out when it notices that we're reusing an existing superblock. Since the existing superblock is already set up and presumably in use, we can't go overwriting its context with the one from the "original" sb. Because of this, the second context= option in this case cannot take effect. This patch fixes this by turning security_sb_clone_mnt_opts into an int return operation. When it finds that the "new" superblock that it has been handed is already set up, it checks to see whether the contexts on the old superblock match it. If it does, then it will just return success, otherwise it'll return -EBUSY and emit a printk to tell the admin why the second mount failed. Note that this patch may cause casualties. The NFSv4 code relies on being able to walk down to an export from the pseudoroot. If you mount filesystems that are nested within one another with different contexts, then this patch will make those mounts fail in new and "exciting" ways. For instance, suppose that /export is a separate filesystem on the server: # mount server:/ /mnt/test1 # mount salusa:/export /mnt/test2 -o context=system_u:object_r:tmp_t:s0 mount.nfs: an incorrect mount option was specified ...with the printk in the ring buffer. Because we *might* eventually walk down to /mnt/test1/export, the mount is denied due to this patch. The second mount needs the pseudoroot superblock, but that's already present with the wrong context. OTOH, if we mount these in the reverse order, then both mounts work, because the pseudoroot superblock created when mounting /export is discarded once that mount is done. If we then however try to walk into that directory, the automount fails for the similar reasons: # cd /mnt/test1/scratch/ -bash: cd: /mnt/test1/scratch: Device or resource busy The story I've gotten from the SELinux folks that I've talked to is that this is desirable behavior. In SELinux-land, mounting the same data under different contexts is wrong -- there can be only one. Cc: Steve Dickson <steved@redhat.com> Cc: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: NJeff Layton <jlayton@redhat.com> Acked-by: NEric Paris <eparis@redhat.com> Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 15 1月, 2013 1 次提交
-
-
由 Paul Moore 提交于
This patch corrects some problems with LSM/SELinux that were introduced with the multiqueue patchset. The problem stems from the fact that the multiqueue work changed the relationship between the tun device and its associated socket; before the socket persisted for the life of the device, however after the multiqueue changes the socket only persisted for the life of the userspace connection (fd open). For non-persistent devices this is not an issue, but for persistent devices this can cause the tun device to lose its SELinux label. We correct this problem by adding an opaque LSM security blob to the tun device struct which allows us to have the LSM security state, e.g. SELinux labeling information, persist for the lifetime of the tun device. In the process we tweak the LSM hooks to work with this new approach to TUN device/socket labeling and introduce a new LSM hook, security_tun_dev_attach_queue(), to approve requests to attach to a TUN queue via TUNSETQUEUE. The SELinux code has been adjusted to match the new LSM hooks, the other LSMs do not make use of the LSM TUN controls. This patch makes use of the recently added "tun_socket:attach_queue" permission to restrict access to the TUNSETQUEUE operation. On older SELinux policies which do not define the "tun_socket:attach_queue" permission the access control decision for TUNSETQUEUE will be handled according to the SELinux policy's unknown permission setting. Signed-off-by: NPaul Moore <pmoore@redhat.com> Acked-by: NEric Paris <eparis@parisplace.org> Tested-by: NJason Wang <jasowang@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 12月, 2012 1 次提交
-
-
由 Kees Cook 提交于
Now that kernel module origins can be reasoned about, provide a hook to the LSMs to make policy decisions about the module file. This will let Chrome OS enforce that loadable kernel modules can only come from its read-only hash-verified root filesystem. Other LSMs can, for example, read extended attributes for signatures, etc. Signed-off-by: NKees Cook <keescook@chromium.org> Acked-by: NSerge E. Hallyn <serge.hallyn@canonical.com> Acked-by: NEric Paris <eparis@redhat.com> Acked-by: NMimi Zohar <zohar@us.ibm.com> Acked-by: NJames Morris <james.l.morris@oracle.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 12 10月, 2012 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 25 9月, 2012 1 次提交
-
-
由 Mark Salter 提交于
Commit 1ad75b9e ("c/r: prctl: add minimal address test to PR_SET_MM") added some address checking to prctl_set_mm() used by checkpoint-restore. This causes a build error for no-MMU systems: kernel/sys.c: In function 'prctl_set_mm': kernel/sys.c:1868:34: error: 'mmap_min_addr' undeclared (first use in this function) The test for mmap_min_addr doesn't make a lot of sense for no-MMU code as noted in commit 6e141546 ("NOMMU: Optimise away the {dac_,}mmap_min_addr tests"). This patch defines mmap_min_addr as 0UL in the no-MMU case so that the compiler will optimize away tests for "addr < mmap_min_addr". Signed-off-by: NMark Salter <msalter@redhat.com> Reviewed-by: NCyrill Gorcunov <gorcunov@openvz.org> Cc: <stable@vger.kernel.org> [3.6.x] Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 9月, 2012 1 次提交
-
-
由 Eric W. Biederman 提交于
Don't make the security modules deal with raw user space uid and gids instead pass in a kuid_t and a kgid_t so that security modules only have to deal with internal kernel uids and gids. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: James Morris <james.l.morris@oracle.com> Cc: John Johansen <john.johansen@canonical.com> Cc: Kentaro Takeda <takedakn@nttdata.co.jp> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: NSerge Hallyn <serge.hallyn@canonical.com> Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
-
- 06 9月, 2012 1 次提交
-
-
由 Kees Cook 提交于
Unconditionally call Yama when CONFIG_SECURITY_YAMA_STACKED is selected, no matter what LSM module is primary. Ubuntu and Chrome OS already carry patches to do this, and Fedora has voiced interest in doing this as well. Instead of having multiple distributions (or LSM authors) carrying these patches, just allow Yama to be called unconditionally when selected by the new CONFIG. Signed-off-by: NKees Cook <keescook@chromium.org> Acked-by: NSerge E. Hallyn <serge.hallyn@canonical.com> Acked-by: NEric Paris <eparis@redhat.com> Acked-by: NJohn Johansen <john.johansen@canonical.com> Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 10 8月, 2012 1 次提交
-
-
由 Kees Cook 提交于
The higher ptrace restriction levels should be blocking even PTRACE_TRACEME requests. The comments in the LSM documentation are misleading about when the checks happen (the parent does not go through security_ptrace_access_check() on a PTRACE_TRACEME call). Signed-off-by: NKees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org # 3.5.x and later Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 01 6月, 2012 3 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
... i.e. file-dependent and address-dependent checks. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
... switch callers. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 14 4月, 2012 1 次提交
-
-
由 Andy Lutomirski 提交于
With this change, calling prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) disables privilege granting operations at execve-time. For example, a process will not be able to execute a setuid binary to change their uid or gid if this bit is set. The same is true for file capabilities. Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that LSMs respect the requested behavior. To determine if the NO_NEW_PRIVS bit is set, a task may call prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0); It returns 1 if set and 0 if it is not set. If any of the arguments are non-zero, it will return -1 and set errno to -EINVAL. (PR_SET_NO_NEW_PRIVS behaves similarly.) This functionality is desired for the proposed seccomp filter patch series. By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the system call behavior for itself and its child tasks without being able to impact the behavior of a more privileged task. Another potential use is making certain privileged operations unprivileged. For example, chroot may be considered "safe" if it cannot affect privileged tasks. Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is set and AppArmor is in use. It is fixed in a subsequent patch. Signed-off-by: NAndy Lutomirski <luto@amacapital.net> Signed-off-by: NWill Drewry <wad@chromium.org> Acked-by: NEric Paris <eparis@redhat.com> Acked-by: NKees Cook <keescook@chromium.org> v18: updated change desc v17: using new define values as per 3.4 Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 10 4月, 2012 1 次提交
-
-
由 Eric Paris 提交于
dentry_open takes a file, rename it to file_open Signed-off-by: NEric Paris <eparis@redhat.com>
-
- 28 2月, 2012 1 次提交
-
-
由 Javier Martinez Canillas 提交于
unix_may_send hook has the prototype: int (*unix_may_send) (struct socket *sock, struct socket *other) so the documentation is wrongly referring to the second argument as @sock. Signed-off-by: NJavier Martinez Canillas <javier@dowhile0.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 14 2月, 2012 2 次提交
-
-
由 Al Viro 提交于
Trim security.h Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NJames Morris <jmorris@namei.org>
-
由 Al Viro 提交于
Collapse security_vm_enough_memory() variants into a single function. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NJames Morris <jmorris@namei.org>
-
- 10 2月, 2012 1 次提交
-
-
由 Kees Cook 提交于
The current LSM interface to cred_free is not sufficient for allowing an LSM to track the life and death of a task. This patch adds the task_free hook so that an LSM can clean up resources on task death. Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NJames Morris <jmorris@namei.org>
-
- 07 1月, 2012 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 06 1月, 2012 5 次提交
-
-
由 Eric Paris 提交于
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>
-
由 Eric Paris 提交于
The name security_real_capable and security_real_capable_noaudit just don't make much sense to me. Convert them to use security_capable and security_capable_noaudit. Signed-off-by: NEric Paris <eparis@redhat.com> Acked-by: NSerge E. Hallyn <serge.hallyn@canonical.com>
-
由 Eric Paris 提交于
Exactly like security_capable except don't audit any denials. This is for places where the kernel may make decisions about what to do if a task has a given capability, but which failing that capability is not a sign of a security policy violation. An example is checking if a task has CAP_SYS_ADMIN to lower it's likelyhood of being killed by the oom killer. This check is not a security violation if it is denied. Signed-off-by: NEric Paris <eparis@redhat.com> Acked-by: NSerge E. Hallyn <serge.hallyn@canonical.com>
-
由 Eric Paris 提交于
security_capable takes ns, cred, cap. But the LSM capable() hook takes cred, ns, cap. The capability helper functions also take cred, ns, cap. Rather than flip argument order just to flip it back, leave them alone. Heck, this should be a little faster since argument will be in the right place! Signed-off-by: NEric Paris <eparis@redhat.com>
-
由 Eric Paris 提交于
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>
-
- 04 1月, 2012 2 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-