From: "Serge E. Hallyn" <serue@us.ibm.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
Stephen Smalley <sds@tycho.nsa.gov>,
James Morris <jmorris@namei.org>,
Chris Wright <chrisw@sous-sol.org>, Andrew Morton <akpm@osdl.org>,
KaiGai Kohei <kaigai@kaigai.gr.jp>,
Chris Friedhoff <chris@friedhoff.org>,
Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH 1/1] security: introduce fs caps
Date: Thu, 9 Nov 2006 00:10:21 -0600 [thread overview]
Message-ID: <20061109061021.GA32696@sergelap.austin.ibm.com> (raw)
In-Reply-To: <20061108222453.GA6408@sergelap.austin.ibm.com>
Sorry, I should have noticed and fixed this much sooner. This
patch is against the latest full fscaps patch which I'm replying
to.
From: Serge E. Hallyn <serue@us.ibm.com>
Date: Thu, 9 Nov 2006 00:01:49 -0600
Subject: security: file caps: fix unused variable warnings
Address warnings of unused variables at cap_bprm_set_security
when file capabilities are disabled, and simultaneously clean
up the code a little, by pulling the new code into a helper
function.
Rename vfs_cap_data_struct to remove redundant '_struct'.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
security/commoncap.c | 73 ++++++++++++++++++++++++++++----------------------
1 files changed, 41 insertions(+), 32 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index 6f5e46c..4b50b4d 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -109,16 +109,17 @@ void cap_capset_set (struct task_struct
target->cap_permitted = *permitted;
}
+#ifdef CONFIG_SECURITY_FS_CAPABILITIES
#define XATTR_CAPS_SUFFIX "capability"
#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
-struct vfs_cap_data_struct {
+struct vfs_cap_data {
__u32 version;
__u32 effective;
__u32 permitted;
__u32 inheritable;
};
-static inline void convert_to_le(struct vfs_cap_data_struct *cap)
+static inline void convert_to_le(struct vfs_cap_data *cap)
{
cap->version = le32_to_cpu(cap->version);
cap->effective = le32_to_cpu(cap->effective);
@@ -126,7 +127,7 @@ static inline void convert_to_le(struct
cap->inheritable = le32_to_cpu(cap->inheritable);
}
-static int check_cap_sanity(struct vfs_cap_data_struct *cap)
+static int check_cap_sanity(struct vfs_cap_data *cap)
{
int i;
@@ -149,39 +150,14 @@ static int check_cap_sanity(struct vfs_c
return 0;
}
-int cap_bprm_set_security (struct linux_binprm *bprm)
+/* Locate any VFS capabilities: */
+static int set_file_caps(struct linux_binprm *bprm)
{
struct dentry *dentry;
ssize_t rc;
- struct vfs_cap_data_struct cap_struct;
+ struct vfs_cap_data cap_struct;
struct inode *inode;
- /* Copied from fs/exec.c:prepare_binprm. */
-
- cap_clear (bprm->cap_inheritable);
- cap_clear (bprm->cap_permitted);
- cap_clear (bprm->cap_effective);
-
- /* To support inheritance of root-permissions and suid-root
- * executables under compatibility mode, we raise all three
- * capability sets for the file.
- *
- * If only the real uid is 0, we only raise the inheritable
- * and permitted sets of the executable file.
- */
-
- if (!issecure (SECURE_NOROOT)) {
- if (bprm->e_uid == 0 || current->uid == 0) {
- cap_set_full (bprm->cap_inheritable);
- cap_set_full (bprm->cap_permitted);
- }
- if (bprm->e_uid == 0)
- cap_set_full (bprm->cap_effective);
- }
-
-#ifdef CONFIG_SECURITY_FS_CAPABILITIES
- /* Locate any VFS capabilities: */
-
dentry = dget(bprm->file->f_dentry);
inode = dentry->d_inode;
if (!inode->i_op || !inode->i_op->getxattr) {
@@ -216,9 +192,42 @@ #ifdef CONFIG_SECURITY_FS_CAPABILITIES
bprm->cap_permitted = cap_struct.permitted;
bprm->cap_inheritable = cap_struct.inheritable;
-#endif
return 0;
}
+#else
+static int set_file_caps(struct linux_binprm *bprm)
+{
+ return 0;
+}
+#endif
+
+int cap_bprm_set_security (struct linux_binprm *bprm)
+{
+ /* Copied from fs/exec.c:prepare_binprm. */
+
+ cap_clear (bprm->cap_inheritable);
+ cap_clear (bprm->cap_permitted);
+ cap_clear (bprm->cap_effective);
+
+ /* To support inheritance of root-permissions and suid-root
+ * executables under compatibility mode, we raise all three
+ * capability sets for the file.
+ *
+ * If only the real uid is 0, we only raise the inheritable
+ * and permitted sets of the executable file.
+ */
+
+ if (!issecure (SECURE_NOROOT)) {
+ if (bprm->e_uid == 0 || current->uid == 0) {
+ cap_set_full (bprm->cap_inheritable);
+ cap_set_full (bprm->cap_permitted);
+ }
+ if (bprm->e_uid == 0)
+ cap_set_full (bprm->cap_effective);
+ }
+
+ return set_file_caps(bprm);
+}
void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
{
--
1.4.1
next prev parent reply other threads:[~2006-11-09 6:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-08 22:24 Serge E. Hallyn
2006-11-08 22:48 ` Alexey Dobriyan
2006-11-08 23:52 ` Serge E. Hallyn
2006-11-09 5:27 ` Alexey Dobriyan
2006-11-09 6:17 ` Serge E. Hallyn
2006-11-13 16:43 ` Serge E. Hallyn
2006-11-13 21:04 ` Alexey Dobriyan
2006-11-14 3:01 ` Serge E. Hallyn
2006-11-09 6:10 ` Serge E. Hallyn [this message]
2006-11-09 9:33 ` Chris Friedhoff
2006-11-09 14:50 ` Bill O'Donnell
2006-11-13 21:57 ` Bill O'Donnell
2006-11-14 5:25 ` Serge E. Hallyn
2006-11-14 13:55 ` Bill O'Donnell
2006-11-14 15:23 ` Serge E. Hallyn
2006-11-14 17:28 ` Chris Friedhoff
2006-11-14 17:40 ` Bill O'Donnell
2006-11-15 12:08 ` KaiGai Kohei
2006-11-15 17:06 ` Bill O'Donnell
2006-11-15 21:49 ` Chris Friedhoff
2006-11-16 14:47 ` Bill O'Donnell
2006-11-17 18:37 ` Chris Friedhoff
2006-11-17 19:12 ` Chris Friedhoff
-- strict thread matches above, loose matches on Subject: below --
2006-11-03 16:57 chris friedhoff
2006-11-03 20:00 ` Serge E. Hallyn
2006-11-03 20:29 ` Stephen Smalley
2006-11-03 20:47 ` Serge E. Hallyn
2006-11-04 2:08 ` Kyle Moffett
2006-11-04 4:12 ` James Morris
2006-11-06 13:31 ` Stephen Smalley
2006-09-06 18:27 Serge E. Hallyn
2006-09-06 20:51 ` Paul Jackson
2006-09-07 1:25 ` Serge E. Hallyn
2006-09-07 6:40 ` Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061109061021.GA32696@sergelap.austin.ibm.com \
--to=serue@us.ibm.com \
--cc=adobriyan@gmail.com \
--cc=akpm@osdl.org \
--cc=chris@friedhoff.org \
--cc=chrisw@sous-sol.org \
--cc=jmorris@namei.org \
--cc=kaigai@kaigai.gr.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®