On Wed, May 06, 2020 at 07:49:20PM +0100, Al Viro wrote:
> On Wed, May 06, 2020 at 08:34:29AM -0700, Kees Cook wrote:
>
> > Just posted the whole series:
> > https://lore.kernel.org/lkml/20200506152114.50375-1-keesc...@chromium.org/
> >
> > But the specific question was driven by this patch:
> >
On Wed, May 06, 2020 at 08:34:29AM -0700, Kees Cook wrote:
> Just posted the whole series:
> https://lore.kernel.org/lkml/20200506152114.50375-1-keesc...@chromium.org/
>
> But the specific question was driven by this patch:
>
On Wed, May 06, 2020 at 05:02:52AM +0100, Al Viro wrote:
> On Tue, May 05, 2020 at 08:28:33PM -0700, Kees Cook wrote:
> > On Wed, May 06, 2020 at 02:14:31AM +0100, Al Viro wrote:
> > > On Tue, May 05, 2020 at 04:40:35PM -0700, Kees Cook wrote:
> > > > After using simple_unlink(), a call to
On Tue, May 05, 2020 at 08:28:33PM -0700, Kees Cook wrote:
> On Wed, May 06, 2020 at 02:14:31AM +0100, Al Viro wrote:
> > On Tue, May 05, 2020 at 04:40:35PM -0700, Kees Cook wrote:
> > > After using simple_unlink(), a call to d_delete() is needed in addition
> > > to dput().
> > >
> > >
On Wed, May 06, 2020 at 02:14:31AM +0100, Al Viro wrote:
> On Tue, May 05, 2020 at 04:40:35PM -0700, Kees Cook wrote:
> > After using simple_unlink(), a call to d_delete() is needed in addition
> > to dput().
> >
> > Signed-off-by: Kees Cook
> > ---
> > Is this correct? I went looking around and
On Tue, May 05, 2020 at 04:40:35PM -0700, Kees Cook wrote:
> After using simple_unlink(), a call to d_delete() is needed in addition
> to dput().
>
> Signed-off-by: Kees Cook
> ---
> Is this correct? I went looking around and there are a lot of variations
> on the simple_unlink() pattern...
>
>
After using simple_unlink(), a call to d_delete() is needed in addition
to dput().
Signed-off-by: Kees Cook
---
Is this correct? I went looking around and there are a lot of variations
on the simple_unlink() pattern...
Many using explicit locking and combinations of d_drop(), __d_drop(), etc.
* Greg KH ([EMAIL PROTECTED]) wrote:
> Chris, care to forward the securityfs patch to Linus?
Yeah, I've got it queued up right now, and I'm playing with it a bit.
As well as this one. Thanks guys.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Quoting Greg KH ([EMAIL PROTECTED]):
> On Thu, Jul 07, 2005 at 05:46:04PM -0500, [EMAIL PROTECTED] wrote:
> >
> > With the obvious fix, that does in fact work (patch appended).
>
> Good.
>
> > The __simple_attr_check_format problem remains however. I assume we
> > don't really want to just
On Fri, Jul 08, 2005 at 03:44:19PM -0500, [EMAIL PROTECTED] wrote:
> Quoting Greg KH ([EMAIL PROTECTED]):
> > On Thu, Jul 07, 2005 at 05:46:04PM -0500, [EMAIL PROTECTED] wrote:
> > >
> > > With the obvious fix, that does in fact work (patch appended).
> >
> > Good.
> >
> > > The
On Fri, Jul 08, 2005 at 03:44:19PM -0500, [EMAIL PROTECTED] wrote:
Quoting Greg KH ([EMAIL PROTECTED]):
On Thu, Jul 07, 2005 at 05:46:04PM -0500, [EMAIL PROTECTED] wrote:
With the obvious fix, that does in fact work (patch appended).
Good.
The __simple_attr_check_format
Quoting Greg KH ([EMAIL PROTECTED]):
On Thu, Jul 07, 2005 at 05:46:04PM -0500, [EMAIL PROTECTED] wrote:
With the obvious fix, that does in fact work (patch appended).
Good.
The __simple_attr_check_format problem remains however. I assume we
don't really want to just take it out,
* Greg KH ([EMAIL PROTECTED]) wrote:
Chris, care to forward the securityfs patch to Linus?
Yeah, I've got it queued up right now, and I'm playing with it a bit.
As well as this one. Thanks guys.
-chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Quoting Greg KH ([EMAIL PROTECTED]):
> On Thu, Jul 07, 2005 at 05:46:04PM -0500, [EMAIL PROTECTED] wrote:
> >
> > With the obvious fix, that does in fact work (patch appended).
>
> Good.
>
> > The __simple_attr_check_format problem remains however. I assume we
> > don't really want to just
On Thu, Jul 07, 2005 at 05:46:04PM -0500, [EMAIL PROTECTED] wrote:
>
> With the obvious fix, that does in fact work (patch appended).
Good.
> The __simple_attr_check_format problem remains however. I assume we
> don't really want to just take it out, though, like this patch does?
No we do
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> Quoting Greg KH ([EMAIL PROTECTED]):
> > > Unfortunately the simple_attr code from libfs really doesn't seem to be
> > > usable for int args.
> >
> > Why not? You want a negative number? Just cast the u64 to a signed int
> > then. Will that not
Quoting Greg KH ([EMAIL PROTECTED]):
> > Unfortunately the simple_attr code from libfs really doesn't seem to be
> > usable for int args.
>
> Why not? You want a negative number? Just cast the u64 to a signed int
> then. Will that not work? If not we can tweak the libfs interface to
> work
Quoting Greg KH ([EMAIL PROTECTED]):
> On Wed, Jul 06, 2005 at 05:08:35PM -0500, [EMAIL PROTECTED] wrote:
> > Quoting Greg KH ([EMAIL PROTECTED]):
> > > think it could be made even smaller if you use the default read and
> > > write file type functions in libfs (look at the debugfs wrappers of
Quoting Greg KH ([EMAIL PROTECTED]):
On Wed, Jul 06, 2005 at 05:08:35PM -0500, [EMAIL PROTECTED] wrote:
Quoting Greg KH ([EMAIL PROTECTED]):
think it could be made even smaller if you use the default read and
write file type functions in libfs (look at the debugfs wrappers of them
for
Quoting Greg KH ([EMAIL PROTECTED]):
Unfortunately the simple_attr code from libfs really doesn't seem to be
usable for int args.
Why not? You want a negative number? Just cast the u64 to a signed int
then. Will that not work? If not we can tweak the libfs interface to
work properly
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
Quoting Greg KH ([EMAIL PROTECTED]):
Unfortunately the simple_attr code from libfs really doesn't seem to be
usable for int args.
Why not? You want a negative number? Just cast the u64 to a signed int
then. Will that not work? If not
On Thu, Jul 07, 2005 at 05:46:04PM -0500, [EMAIL PROTECTED] wrote:
With the obvious fix, that does in fact work (patch appended).
Good.
The __simple_attr_check_format problem remains however. I assume we
don't really want to just take it out, though, like this patch does?
No we do not.
Quoting Greg KH ([EMAIL PROTECTED]):
On Thu, Jul 07, 2005 at 05:46:04PM -0500, [EMAIL PROTECTED] wrote:
With the obvious fix, that does in fact work (patch appended).
Good.
The __simple_attr_check_format problem remains however. I assume we
don't really want to just take it out,
On Wed, 2005-07-06 at 11:35 -0400, James Morris wrote:
> When exactly is this needed? The securityfs mountpoint will be available
> via a core_initcall, after which we can initialize the selinux subtree.
As long as it occurs prior to initial policy load, so that should be
fine.
> With
On Wed, 6 Jul 2005, Stephen Smalley wrote:
> > Stephen: opinions on this?
>
> The reason for creating a kernel mount of selinuxfs at that point is so
> that the selinuxfs_mount vfsmount and selinux_null dentry are available
> for flush_unauthorized_files to use.
When exactly is this needed?
On Wed, Jul 06, 2005 at 12:06:40PM -0400, Stephen Smalley wrote:
> > I think it should reduce and simplify the SELinux kernel code, with less
> > filesystems in the kernel, consolidating several potential projects into
> > the same security filesystem.
>
> If there are several such projects in
* Stephen Smalley ([EMAIL PROTECTED]) wrote:
> It still has to be mounted by userspace, right? So /sbin/init still
> needs to know to mount securityfs, and where the selinux nodes live
> under it, so you are still talking about changing it (and libselinux and
> rc.sysinit), and risking
On Wed, Jul 06, 2005 at 05:08:35PM -0500, [EMAIL PROTECTED] wrote:
> Quoting Greg KH ([EMAIL PROTECTED]):
> > think it could be made even smaller if you use the default read and
> > write file type functions in libfs (look at the debugfs wrappers of them
> > for u8, u16, etc, for examples of how
Quoting Greg KH ([EMAIL PROTECTED]):
> > Or is there a better way to do this?
>
> Look at how debugfs uses the libfs code. We should not need to add
> these handlers to securityfs.
Ah, ok, thanks. I think I've got it - will send out a new patch tomorrow.
thanks,
-serge
-
To unsubscribe from
Quoting Greg KH ([EMAIL PROTECTED]):
> think it could be made even smaller if you use the default read and
> write file type functions in libfs (look at the debugfs wrappers of them
> for u8, u16, etc, for examples of how to use them.)
The attached patch cleans up the securelevel code for the
On Wed, 2005-07-06 at 02:52 -0400, James Morris wrote:
> On Sun, 3 Jul 2005, Greg KH wrote:
>
> > Good idea. Here's a patch to do just that (compile tested only...)
> >
> > Comments?
>
> Looks promising so far.
>
> I'm currently porting selinuxfs funtionality to securityfs, although I'm
> not
Quoting Greg KH ([EMAIL PROTECTED]):
> Nice, glad to see this makes your code smaller and simpler. Although I
> think it could be made even smaller if you use the default read and
> write file type functions in libfs (look at the debugfs wrappers of them
> for u8, u16, etc, for examples of how to
On Wed, Jul 06, 2005 at 02:52:47AM -0400, James Morris wrote:
> On Sun, 3 Jul 2005, Greg KH wrote:
>
> > Good idea. Here's a patch to do just that (compile tested only...)
> >
> > Comments?
>
> Looks promising so far.
>
> I'm currently porting selinuxfs funtionality to securityfs, although
On Sun, 3 Jul 2005, Greg KH wrote:
> Good idea. Here's a patch to do just that (compile tested only...)
>
> Comments?
Looks promising so far.
I'm currently porting selinuxfs funtionality to securityfs, although I'm
not sure if we'll be ok during early initialization. selinuxfs is
currently
On Sun, 3 Jul 2005, Greg KH wrote:
Good idea. Here's a patch to do just that (compile tested only...)
Comments?
Looks promising so far.
I'm currently porting selinuxfs funtionality to securityfs, although I'm
not sure if we'll be ok during early initialization. selinuxfs is
currently
On Wed, Jul 06, 2005 at 02:52:47AM -0400, James Morris wrote:
On Sun, 3 Jul 2005, Greg KH wrote:
Good idea. Here's a patch to do just that (compile tested only...)
Comments?
Looks promising so far.
I'm currently porting selinuxfs funtionality to securityfs, although I'm
not sure
Quoting Greg KH ([EMAIL PROTECTED]):
Nice, glad to see this makes your code smaller and simpler. Although I
think it could be made even smaller if you use the default read and
write file type functions in libfs (look at the debugfs wrappers of them
for u8, u16, etc, for examples of how to use
On Wed, 2005-07-06 at 02:52 -0400, James Morris wrote:
On Sun, 3 Jul 2005, Greg KH wrote:
Good idea. Here's a patch to do just that (compile tested only...)
Comments?
Looks promising so far.
I'm currently porting selinuxfs funtionality to securityfs, although I'm
not sure if
Quoting Greg KH ([EMAIL PROTECTED]):
think it could be made even smaller if you use the default read and
write file type functions in libfs (look at the debugfs wrappers of them
for u8, u16, etc, for examples of how to use them.)
The attached patch cleans up the securelevel code for the seclvl
Quoting Greg KH ([EMAIL PROTECTED]):
Or is there a better way to do this?
Look at how debugfs uses the libfs code. We should not need to add
these handlers to securityfs.
Ah, ok, thanks. I think I've got it - will send out a new patch tomorrow.
thanks,
-serge
-
To unsubscribe from this
On Wed, Jul 06, 2005 at 05:08:35PM -0500, [EMAIL PROTECTED] wrote:
Quoting Greg KH ([EMAIL PROTECTED]):
think it could be made even smaller if you use the default read and
write file type functions in libfs (look at the debugfs wrappers of them
for u8, u16, etc, for examples of how to use
* Stephen Smalley ([EMAIL PROTECTED]) wrote:
It still has to be mounted by userspace, right? So /sbin/init still
needs to know to mount securityfs, and where the selinux nodes live
under it, so you are still talking about changing it (and libselinux and
rc.sysinit), and risking compatibility
On Wed, Jul 06, 2005 at 12:06:40PM -0400, Stephen Smalley wrote:
I think it should reduce and simplify the SELinux kernel code, with less
filesystems in the kernel, consolidating several potential projects into
the same security filesystem.
If there are several such projects in the first
On Wed, 6 Jul 2005, Stephen Smalley wrote:
Stephen: opinions on this?
The reason for creating a kernel mount of selinuxfs at that point is so
that the selinuxfs_mount vfsmount and selinux_null dentry are available
for flush_unauthorized_files to use.
When exactly is this needed? The
On Wed, 2005-07-06 at 11:35 -0400, James Morris wrote:
When exactly is this needed? The securityfs mountpoint will be available
via a core_initcall, after which we can initialize the selinux subtree.
As long as it occurs prior to initial policy load, so that should be
fine.
With securityfs,
On Mon, Jul 04, 2005 at 10:53:21AM -0500, [EMAIL PROTECTED] wrote:
> > On Sun, Jul 03, 2005 at 02:53:17PM -0400, James Morris wrote:
> > > On Sun, 3 Jul 2005, Tony Jones wrote:
> > >
> > > > There just isn't enough content to justify a stacker specific
> > > > filesystem IMHO.
> > >
> > > It
On Mon, Jul 04, 2005 at 10:53:21AM -0500, [EMAIL PROTECTED] wrote:
On Sun, Jul 03, 2005 at 02:53:17PM -0400, James Morris wrote:
On Sun, 3 Jul 2005, Tony Jones wrote:
There just isn't enough content to justify a stacker specific
filesystem IMHO.
It might be worth thinking
Quoting Greg KH ([EMAIL PROTECTED]):
> On Sun, Jul 03, 2005 at 02:53:17PM -0400, James Morris wrote:
> > On Sun, 3 Jul 2005, Tony Jones wrote:
> >
> > > There just isn't enough content to justify a stacker specific filesystem
> > > IMHO.
> >
> > It might be worth thinking about a more general
Quoting Greg KH ([EMAIL PROTECTED]):
> On Sun, Jul 03, 2005 at 02:53:17PM -0400, James Morris wrote:
> > On Sun, 3 Jul 2005, Tony Jones wrote:
> >
> > > There just isn't enough content to justify a stacker specific filesystem
> > > IMHO.
> >
> > It might be worth thinking about a more general
Quoting Greg KH ([EMAIL PROTECTED]):
On Sun, Jul 03, 2005 at 02:53:17PM -0400, James Morris wrote:
On Sun, 3 Jul 2005, Tony Jones wrote:
There just isn't enough content to justify a stacker specific filesystem
IMHO.
It might be worth thinking about a more general securityfs as
Quoting Greg KH ([EMAIL PROTECTED]):
On Sun, Jul 03, 2005 at 02:53:17PM -0400, James Morris wrote:
On Sun, 3 Jul 2005, Tony Jones wrote:
There just isn't enough content to justify a stacker specific filesystem
IMHO.
It might be worth thinking about a more general securityfs as
51 matches
Mail list logo
