From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
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>
Subject: Re: [PATCH 1/1] security: introduce fs caps
Date: Mon, 13 Nov 2006 21:01:24 -0600 [thread overview]
Message-ID: <20061114030124.GA31893@sergelap> (raw)
In-Reply-To: <20061113210443.GD4971@martell.zuzino.mipt.ru>
Quoting Alexey Dobriyan (adobriyan@gmail.com):
> On Mon, Nov 13, 2006 at 10:43:26AM -0600, Serge E. Hallyn wrote:
> > Quoting Alexey Dobriyan (adobriyan@gmail.com):
> > > On Wed, Nov 08, 2006 at 05:52:03PM -0600, Serge E. Hallyn wrote:
> > > > > > + __u32 version;
> > > > > > + __u32 effective;
> > > > > > + __u32 permitted;
> > > > > > + __u32 inheritable;
> > > > > > +};
> > > > > > +
> > > > > > +static inline void convert_to_le(struct vfs_cap_data_struct *cap)
> > > > > > +{
> > > > > > + cap->version = le32_to_cpu(cap->version);
> > > > > > + cap->effective = le32_to_cpu(cap->effective);
> > > > > > + cap->permitted = le32_to_cpu(cap->permitted);
> > > > > > + cap->inheritable = le32_to_cpu(cap->inheritable);
> > > > > > +}
> > > > >
> > > > > This pretty much defeats sparse endian checking. You will get warnings
> > > > > regardless of whether u32 or le32 are used.
> > > >
> > > > But I don't get any sparse warnings with make C=1. Am I doing something
> > > > wrong?
> > >
> > > You need (temporarily) to use CF:
> > >
> > > make C=1 CF=-D__CHECK_ENDIAN__ ...
> >
> > The following patch on top of the existing one eliminates the warning.
> > Does it appear consistent with what you were suggesting?
>
> > If it is ok, I'll resend the full patch.
>
> Yes, that's it, modulo:
Thanks, comments integrated with the exception of:
> > --- a/include/linux/capability.h
> > +++ b/include/linux/capability.h
> > +#ifdef CONFIG_SECURITY_FS_CAPABILITIES
>
> This is exportable header, so no CONFIG_*
>
> > +#define XATTR_CAPS_SUFFIX "capability"
> > +#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
> > +struct vfs_cap_data_disk {
> > + __le32 version;
> > + __le32 effective;
> > + __le32 permitted;
> > + __le32 inheritable;
> > +};
> > +#endif
> >
> > #ifdef __KERNEL__
> >
> > #include <linux/spinlock.h>
> > #include <asm/current.h>
> >
> > +#ifdef CONFIG_SECURITY_FS_CAPABILITIES
> > +struct vfs_cap_data {
> > + __u32 version;
> > + __u32 effective;
> > + __u32 permitted;
> > + __u32 inheritable;
> > +};
>
> Now you're in kernel, so you can happily use u32 without undescores.
The rest of the file already uses __u32, so for consistency I'd
rather stick with __u32, unless there's a reason why it's really
discouraged.
Will send new patch in just a bit.
thanks,
-serge
> > --- a/security/commoncap.c
> > +++ b/security/commoncap.c
> > @@ -155,7 +147,8 @@ static int set_file_caps(struct linux_bi
> > {
> > struct dentry *dentry;
> > ssize_t rc;
>
> > @@ -178,19 +171,19 @@ static int set_file_caps(struct linux_bi
> > return rc;
> > }
> >
> > - if (rc != sizeof(cap_struct)) {
> > + if (rc != sizeof(dcaps)) {
> > printk(KERN_NOTICE "%s: got wrong size for getxattr (%d)\n",
> > __FUNCTION__, rc);
>
> rc is ssize_t, so "%zd".
next prev parent reply other threads:[~2006-11-14 3:04 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-08 22:24 [PATCH 1/1] security: introduce fs caps 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 [this message]
2006-11-09 6:10 ` Serge E. Hallyn
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=20061114030124.GA31893@sergelap \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.