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:
> https://lore.kernel.org/lkml/20200506152114.50375-11-keesc...@chromium.
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 d_delete
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().
> > >
> > > Signed-off
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...
>
>
* 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 m
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
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_ch
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
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 [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 w
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 pro
On Thu, Jul 07, 2005 at 12:30:35PM -0500, [EMAIL PROTECTED] wrote:
> 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
> >
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
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 securityf
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, 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
* 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 compatibili
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
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 th
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 secl
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 I'm
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 ke
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 mig
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 se
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 se
29 matches
Mail list logo
