Andrew Morton [EMAIL PROTECTED] wrote:
Hmmm you're right. Is your security work going into the next -mm?
I don't know. Andrew hasn't said anything. Andrew? Are you waiting for it
to go through DaveM's networking tree?
AF_RXRPC is a davem thing and AFS: Add security support and
Nate Diller [EMAIL PROTECTED] wrote:
but that's a lot of code to avoid a single stack allocation. The
whole fake file pointer thing still strikes me as a little ugly, and
you're definitely not the first one who needed this sort of hackery.
ugh
A better way might be to stick a void * in
Nick Piggin [EMAIL PROTECTED] wrote:
I think I should put wait_lock after wait_list, so as to get a better
packing on most 64-bit architectures.
It makes no difference. struct lockdep_map contains at least one pointer and
so is going to be 8-byte aligned (assuming it's there at all). struct
Nick Piggin [EMAIL PROTECTED] wrote:
This patch converts all architectures to a generic rwsem implementation,
which will compile down to the same code for i386, or powerpc, for
example,
and will allow some (eg. x86-64) to move away from spinlock based rwsems.
Which are better on UP kernels
Nick Piggin [EMAIL PROTECTED] wrote:
The other way happens to be better for everyone else, which is why I
think your suggestion to instead move everyone to the spinlock version
was weird.
No, you misunderstand me. My preferred solution is to leave it up to the arch
and not to make it
Eric Dumazet [EMAIL PROTECTED] wrote:
If space considerations are that important, we could then reserve one bit
for the 'wait_lock spinlock'
That makes life quite a bit more tricky, though it does have the advantage
that it closes the reader-jumping-writer window I mentioned.
Another
attention to the refcount on dev? I assume not...
Should you clear p-dev-br_port before calling dev_put()?
Looks reasonable. I like it.
Acked-By: David Howells [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Core dumping is separated two phases, one is the phase of writing
headers, the other is the phase of writing memory segments. If the
coredump_omit_anon_shared setting is changed between these two phases,
a corrupted core file will be generated because
From: David Howells [EMAIL PROTECTED]
FRV does not require a ZONE_DMA, so all DMA'able pages that aren't highmem
should be in ZONE_NORMAL.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
arch/frv/mm/init.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/frv
From: David Howells [EMAIL PROTECTED]
linux/irq.h uses EINVAL but does not #include linux/errno.h. This results in
the compiler spitting out errors on some files.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/linux/irq.h |1 +
1 files changed, 1 insertions(+), 0 deletions
From: David Howells [EMAIL PROTECTED]
Add some missing lazy MMU hooks for NOMMU mode.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/asm-frv/pgtable.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/asm-frv/pgtable.h b/include/asm-frv/pgtable.h
Adrian Bunk [EMAIL PROTECTED] wrote:
} /* end rxrpc_create_call() */
+EXPORT_SYMBOL(rxrpc_create_call);
A blank line between the end of the function and the EXPORT_SYMBOL please.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
From: David Howells [EMAIL PROTECTED]
Add support for direct mapping through mtdconcat, if possible, by attaching the
samebacking_dev_info structure to the master.
It has some restrictions:
(1) It won't permit direct mapping of concatenated devices that have differing
BDIs.
(2
From: David Howells [EMAIL PROTECTED]
Present backing device capabilities for MTD character device files to allow
NOMMU mmap to do direct mapping where possible.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
drivers/mtd/Makefile |2 +
drivers/mtd/chips/map_ram.c | 17
From: David Howells [EMAIL PROTECTED]
Generalise the handling of MTD-specific superblocks so that JFFS2 and ROMFS can
both share it.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
drivers/mtd/Makefile |2
drivers/mtd/mtdsuper.c| 231
From: David Howells [EMAIL PROTECTED]
Change RomFS so that it can use MTD devices directly - without the intercession
of the block layer - as well as using block devices.
This permits RomFS:
(1) to use the MTD direct mapping facility available under NOMMU conditions if
the underlying
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
core dumping.
No, it doesn't. Look again:
int do_coredump(long signr, int exit_code, struct pt_regs * regs)
{
setup vars
extensions (such as
SEEK_DATA and SEEK_HOLE). If anyone has a problem with this, please speak up.
Seems reasonable.
Acked-By: David Howells [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
From: David Howells [EMAIL PROTECTED]
Add support for direct mapping through mtdconcat, if possible, by attaching the
samebacking_dev_info structure to the master.
It has some restrictions:
(1) It won't permit direct mapping of concatenated devices that have differing
BDIs.
(2
From: David Howells [EMAIL PROTECTED]
Present backing device capabilities for MTD character device files to allow
NOMMU mmap to do direct mapping where possible.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
drivers/mtd/Makefile |2 +
drivers/mtd/chips/map_ram.c | 17
From: David Howells [EMAIL PROTECTED]
Change RomFS so that it can use MTD devices directly - without the intercession
of the block layer - as well as using block devices.
This permits RomFS:
(1) to use the MTD direct mapping facility available under NOMMU conditions if
the underlying
From: David Howells [EMAIL PROTECTED]
Generalise the handling of MTD-specific superblocks so that JFFS2 and ROMFS can
both share it.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
drivers/mtd/Makefile |2
drivers/mtd/mtdsuper.c| 231
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Okay, the probability that the process is blocked in the proc handler seems
to be small. But I'm not sure if problems never occur in enterprise use.
So I'd like to use down_write_trylock() as Robin said before. And if it
fails to acquire the lock, it
Andrew Morton [EMAIL PROTECTED] wrote:
+ brelse(bh);
A little fyi: brelse() is rather old-fashioned, and has a usually unneeded
test for non-null bh in it. In situations where we know that the pointer is
valid, let's please use put_bh().
That's what was in the old romfs. I
Markus Gutschke [EMAIL PROTECTED] wrote:
As an alternative to your kernel patch, you could achieve the same goal in
user space, by linking my coredumper
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace
Markus Gutschke [EMAIL PROTECTED] wrote:
How does it work when you can't actually get back to userspace to have
userspace do the coredump? You still have to handle the userspace
equivalents of double/triple faults.
My experience shows that there are only very rare occurrences of
Oleg Nesterov [EMAIL PROTECTED] wrote:
Delete NOAUTOREL support
Yay!
and rename work_release to work_clear_pending to avoid a confusion.
Can you add a comment to the effect that this is a function for internal use
only? Or maybe make it __work_clear_pending()?
Acked-By: David Howells
Pavel Machek [EMAIL PROTECTED] wrote:
By same argument, we should just give up the coredumping in kernel. It
is rarely tested, so someone will just get it wrong.
Not so rare... Lots of people still use Evolution after all:-)
However, to counter your point, I'll point out that there's just
Hugh Dickins [EMAIL PROTECTED] wrote:
VMAs are a shared resource under NOMMU conditions.
That's a disturbing remark.
Why? No-one complained when I first put up my rewrite patches three years ago.
Under precisely what NOMMU conditions?
CONFIG_MMU=n.
I had thought Robin's suggestion
From: David Howells [EMAIL PROTECTED]
Hide struct vm_area_struct::vm_mm when in NOMMU mode as this isn't used there.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/linux/mm.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/mm.h b/include
Andrew Morton [EMAIL PROTECTED] wrote:
So we require that one of these be enabled if ROMFS.
At least one, yes. Both can be enabled. I don't know how to do it though.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Adrian Bunk [EMAIL PROTECTED] wrote:
Is
CONFIG_BLOCK=y
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_ON_BLOCK=n
CONFIG_ROMFS_ON_MTD=y
a reasonable configuration that should be supported, or can we turn
CONFIG_ROMFS_ON_BLOCK always on if CONFIG_BLOCK=y?
Hmmm... I don't really know the answer to
then the CONFIG_ROMFS_ON_BLOCK
configuration item disappears and reappears depending on the state of
CONFIG_ROMFS_ON_MTD. But, as I said, it's a very minor niggle.
Acked-By: David Howells [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Wu, Bryan [EMAIL PROTECTED] wrote:
When adding utrace support to blackfin architecture, I found a compiling
error in nommu related utrace stuff. Then this little patch will fix
this for nommu arch utrace.
You really don't want to do it like this. This prevents ELF shared libraries
from being
From: David Howells [EMAIL PROTECTED]
Fix get_order() to use ilog2() properly.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/asm-generic/page.h | 14 +++---
include/linux/log2.h | 20 ++--
2 files changed, 29 insertions(+), 5 deletions(-)
diff
Linus Torvalds [EMAIL PROTECTED] wrote:
Yeah, I think the recent get_order() changes to change it to use ilog2()
are just crap. I actually looked at it when it went in, but I assumed that
it had been tested. I don't think it has.
It had, it's just that the testing totally failed to show up
Hugh Dickins [EMAIL PROTECTED] wrote:
Under precisely what NOMMU conditions?
CONFIG_MMU=n.
Believe it or not, I had just about grasped that subtlety. I was
rather expecting some helpful response along the lines of we share
all the vmas across a fork or whenever we go to allocate a
H. Peter Anvin [EMAIL PROTECTED] wrote:
if (size = (1UL page_shift))
return 0;
else
return __ilog2_u32(size-1)+1-page_shift;
I think you're right. That'll also defend against the result of __ilog2_u32()
being less than page_shift-1.
I think I can
From: David Howells [EMAIL PROTECTED]
Provide an ilog2_up() that rounds its result up (ilog2() rounds down).
Fix get_order() to use ilog2_up() not ilog2() to get the correct rounding.
Adjust the documentation surrounding ilog2() and co. to indicate what rounding
they perform.
Fix
H. Peter Anvin [EMAIL PROTECTED] wrote:
Eh? roundup_pow_of_two(1) should be 0; 2^0 = 1.
Nonono.
roundup_pow_of_two(0) = ?
roundup_pow_of_two(1) = 1
roundup_pow_of_two(2) = 2
roundup_pow_of_two(3) = 4
roundup_pow_of_two(4) = 4
H. Peter Anvin [EMAIL PROTECTED] wrote:
Why not just make it ((n) 1 ? 0 : ...) and make it well-defined for
n == 0?
Because log2(0) is -INF or mathematically undefined or something isn't it?
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Linus Torvalds [EMAIL PROTECTED] wrote:
That seems bogus. n == 1 should give 0, no?
Sigh. No. The comment header says it all:
/**
* roundup_pow_of_two - round the given value up to nearest power of two
* @n - parameter
*
* round the given value up
Alexey Dobriyan [EMAIL PROTECTED] wrote:
#if BITS_PER_LONG == 32 defined(ARCH_HAS_ILOG2_U32)
There is no such thing except on FRV, where it's redundant.
Redundant in what way?
CONFIG_ARCH_HAS_ILOG2_U32
^^
From: David Howells [EMAIL PROTECTED]
Use CONFIG_ARCH_HAS_ILOG2_xxx in __get_order() not ARCH_HAS_ILOG2_xxx as the
former is the right thing to use.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/asm-generic/page.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff
Roland McGrath [EMAIL PROTECTED] wrote:
That old ptrace check seems pretty questionable to me. I think what you
want is for the nommu world's get_user_pages/access_process_vm when called
with force=1,write=1 on a read-only MAP_PRIVATE page to do something more
morally similar to the mmu
Linus Torvalds [EMAIL PROTECTED] wrote:
+#define ilog2_up(n) ((n) == 1 ? 0 : ilog2((n) - 1) + 1)
This is wrong. It uses n twice, which makes it unsafe as a macro.
Damn. I missed that.
Or it could use a __builtin_constant_p() (which gcc defines to not have
side effects) to allow the
Mike Frysinger [EMAIL PROTECTED] wrote:
That sounds reasonable. However, I suspect that most NOMMU CPUs won't be
able to do that. In effect you're creating a third option, I think (MMU,
NOMMU, MPU).
sure, but i'm not sure the MPU option would be mutually exclusive with
NOMMU ... in
Pavel Machek [EMAIL PROTECTED] wrote:
Userland core dumper is useful because it is relatively easy to be
customized, but its reliability highly depends on the application
programs.
Fix userland core dumper to be reliable, then.
I don't think it's that easy. The userland core dumper, as
Wu, Bryan [EMAIL PROTECTED] wrote:
It takes lots of time in malloc()-mmap()-do_mmap_private()-memset(). When
malloc a big area, memset() the area to zero makes the performance very bad.
Ummm...
How do you then cope with attempting to run that same application under
MMU-mode Linux? Won't MMU
Aubrey Li [EMAIL PROTECTED] wrote:
malloc() allocates size bytes and returns a pointer to the allocated memory.
The memory is not cleared.
But this is *not* malloc(). It's mmap(). Are you prepared to guarantee that
there are no applications out there that don't rely on anon mmap()
Aubrey Li [EMAIL PROTECTED] wrote:
Summary is, when I run the app time test,
on x86:
real0m0.066s
user0m0.008s
sys 0m0.058s
on Blackfin:
real3m 37.69s
user0m 0.04s
sys 3m 37.58s
That's not a good comparison: you're comparing two different machines of two
Andrew Morton [EMAIL PROTECTED] wrote:
would anyone be interested in hearing my opinion on the DUMP_SEEK macro
again?
I can guess. And it's very probably right. Macros containing return
statements like that are dodgy as they help people screw up the error handling.
However, ...
Andrew
Hugh Dickins [EMAIL PROTECTED] wrote:
No, I think that's wrong: whereas the binfmt_elf one did its
page_cache_release down below at the bottom of the block, this
version does it in each subblock,
All but the first, which is why there's not a common one post if-complex.
so there you're
Andrew Morton [EMAIL PROTECTED] wrote:
Yes, I agree - I don't think we presently have a way of avoiding having
to send all of that uninteresting data down the pipe.
Have the kernel fork and exec a debug program just in time with the dying
process ptrace-attached in advance. That program could
The first of these patches together provide secure client-side RxRPC
connectivity as a Linux kernel socket family. Only the RxRPC transport/session
side is supplied - the presentation side (marshalling the data) is left to the
client. Copies of the patches can be found here:
Move generic skbuff stuff from XFRM code to generic code so that AF_RXRPC can
use it too.
The kdoc comments I've attached to the functions needs to be checked by whoever
wrote them as I had to make some guesses about the workings of these functions.
Signed-Off-By: David Howells [EMAIL PROTECTED
, on the other hand, is done through the
scatter-gather list interface as the amount of data is sufficient that the
expense of doing virtual address to page calculations is sufficiently small by
comparison.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
crypto/blkcipher.c |2 +
crypto/pcbc.c
Export try_to_del_timer_sync() for use by the RxRPC module.
Add a try_to_cancel_delayed_work() so that it is possible to merely attempt to
cancel a delayed work timer.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/linux/workqueue.h | 21 +
kernel/timer.c
-Off-By: David Howells [EMAIL PROTECTED]
---
Documentation/keys.txt | 12
include/linux/key.h |2 ++
security/keys/keyring.c |2 ++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/keys.txt b/Documentation/keys.txt
index 60c665d..81d9aa0
Mention the slab name when listing corrupt objects. Although the function
that released the memory is mentioned, that is frequently ambiguous as such
functions often release several pieces of memory.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
mm/slab.c |4 ++--
1 files changed, 2
the error number from a local or network error message.
int rxrpc_kernel_get_error_number(struct sk_buff *skb);
This is used to extract the error number from a message indicating either
a local error occurred or a network error occurred.
Signed-Off-By: David Howells [EMAIL PROTECTED
Move generic skbuff stuff from XFRM code to generic code so that AF_RXRPC can
use it too.
The kdoc comments I've attached to the functions needs to be checked by whoever
wrote them as I had to make some guesses about the workings of these functions.
Signed-Off-By: David Howells [EMAIL PROTECTED
-Off-By: David Howells [EMAIL PROTECTED]
---
Documentation/keys.txt | 12
include/linux/key.h |2 ++
security/keys/keyring.c |2 ++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/keys.txt b/Documentation/keys.txt
index 60c665d..81d9aa0
Export try_to_del_timer_sync() for use by the RxRPC module.
Add a try_to_cancel_delayed_work() so that it is possible to merely attempt to
cancel a delayed work timer.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/linux/workqueue.h | 21 +
kernel/timer.c
the error number from a local or network error message.
int rxrpc_kernel_get_error_number(struct sk_buff *skb);
This is used to extract the error number from a message indicating either
a local error occurred or a network error occurred.
Signed-Off-By: David Howells [EMAIL PROTECTED
The first of these patches together provide secure client-side RxRPC
connectivity as a Linux kernel socket family. Only the RxRPC transport/session
side is supplied - the presentation side (marshalling the data) is left to the
client. Copies of the patches can be found here:
Hi Al,
I'd like you to consider approving something like the attached patch. It
allows a key to be obtained by a filesystem during a pathwalk to be used in
subsequent operations in the pathwalk.
The way I envision it working is this:
(1) The nameidata::key pointer is initialised to NULL at
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
- if (!(flags MAP_SHARED))
+ /* Deal with MAP_FIXED differently ? Forbid it ? Need help from some
nommu
+ * folks there... --BenH.
+ */
+ if ((flags MAP_FIXED) || !(flags MAP_SHARED))
MAP_FIXED on NOMMU? Surely you
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
+ if (flags MAP_FIXED)
+ if ((addr PAGE_SHIFT) != pgoff)
+ return (unsigned long) -EINVAL;
Again... in NOMMU-mode there is no MAP_FIXED - it's rejected before we get
this far.
- return pgoff;
+
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
This serie of patches moves the logic to handle MAP_FIXED down to the
various arch/driver get_unmapped_area() implementations, and then changes
the generic code to always call them. The hugetlbfs hacks then disappear
from the generic code.
This
Andrew Morton [EMAIL PROTECTED] wrote:
What we effectively have is 32 threads on a single CPU all doing
for (ever) {
down_write()
up_write()
down_read()
up_read();
}
That's not quite so. In that test program, most
Nick Piggin [EMAIL PROTECTED] wrote:
No. I mean call the bit PG_private2. That way non-pagecache and
filesystems that don't use fscache can use it.
The bit is called PG_owner_priv_2, and then 'subclassed' to PG_fscache, much
like PG_owner_priv_1 is 'subclassed' to PG_checked as was
Sam Ravnborg [EMAIL PROTECTED] wrote:
David - will you look into this?
Do you have a config?
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
[arch/x86/kernel/smpboot_64.c]
void do_fork_idle(struct work_struct *work)
Needs labelling with __cpuinit.
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Label x86 do_fork_idle() with __cpuinit to avoid getting linker warnings when
it references fork_idle(). Also make it static.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
arch/x86/kernel/smpboot_64.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86
Nick Piggin [EMAIL PROTECTED] wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
No. I mean call the bit PG_private2. That way non-pagecache and
filesystems that don't use fscache can use it.
The bit is called PG_owner_priv_2, and then 'subclassed' to PG_fscache,
much like PG_owner_priv_1
read_cache_pages()? Or can
you accept that sharing is sufficient, especially if PG_private_2 now
exists?
David
---
FS-Cache: Recruit a couple of page flags for cache management
From: David Howells [EMAIL PROTECTED]
Recruit a couple of page flags to aid in cache management. The following
Okay. I can:
(1) Have cachefilesd (the daemon) pass a security context string to the
cachefiles kernel module, which can then convert it to a secID. It'll
require a security_secctx_to_secid() function, but I'm fairly certain I
have a patch to add such kicking around somewhere.
David Howells [EMAIL PROTECTED] wrote:
Now, I recall the addition of another security class being mentioned, which
presumably would give something like:
avc_has_perm(daemon_tsec-sid, nominated_sid,
SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
H... I can't
Stephen Smalley [EMAIL PROTECTED] wrote:
Right, the latter is reasonable.
Requires adding the class and permission definition to
policy/flask/security_classes and policy/flask/access_vectors and then
regenerating the kernel headers from those files, ala:
svn co
Stephen Smalley [EMAIL PROTECTED] wrote:
If you have a SELinux: policy loaded with handle_unknown=allow
message in your /var/log/messages, then new classes/perms that are not
yet known to the policy will be allowed by default, so the operation
will be permitted by the kernel.
I don't. How
Stephen Smalley [EMAIL PROTECTED] wrote:
avc_has_perm(daemon_tsec-sid, nominated_sid,
SECCLASS_CACHE, CACHE__USE_AS_OVERRIDE, NULL);
And I assume this doesn't care if one, the other or both of the two SIDs
mentioned are of SECCLASS_PROCESS rather than of
David Howells [EMAIL PROTECTED] wrote:
Okay... It looks like I want four security operations/hooks for cachefiles:
FYI, I added the following vectors:
# kernel services that need to override task security
class kernel_service
{
use_as_override
Casey Schaufler [EMAIL PROTECTED] wrote:
Yes, and I would recommend doing so to avoid permission races.
You're going to have to deal with the case where step (2) fails
even if you have step (1), so the test and set mindset seems
prudent to me.
Looking at SELinux, that doesn't get rid of the
Linus Torvalds [EMAIL PROTECTED] wrote:
That current_cred thing is really too ugly to live.
Agreed.
Why is it trying to make it look like a variable?
Like 'current' for instance?
static __always_inline struct task_struct *get_current(void)
{
return
[EMAIL PROTECTED] wrote:
Due to commit 02a5e0acb3cb85d80d0fe834e366d38a92bbaa22
kernel build is broken if (CONFIG_COMPAT ! CONFIG_BLOCK):
...
... or better apply the attached patch to fix it.
Acked-By: David Howells [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
Andrew Morton [EMAIL PROTECTED] wrote:
So who's going to review this? Nobody? Well gee, maybe it was my turn
anyway.
Well, Kevin Coffman has reviewed it and tested it against his NFS keys patches.
checkpatch generates a pile of warnings, all of which afacit are legit.
For this warning:
Ulrich Drepper [EMAIL PROTECTED] wrote:
In sys_faccessat you temporarily allocate a cred object which is
discarded in the end. With a few more macro definitions you could
create a dup_cred variant which initialized an automatic variable of
type struct cred. This way the kmalloc/kfree pair
that they're -Wformat checked even if they
are disabled, and make it so they can be enabled simply by defining
__KDEBUG to be consistent with other code of mine.
(4) Documentation.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
Documentation/keys-request-key.txt | 25 +-
Documentation
David Howells [EMAIL PROTECTED] wrote:
(1) Permit one process to change another process's cred struct. This means
that a process wishing to read its own creds must use RCU read to do so,
and a lock must be held when replacing the cred struct.
Having thought about this some more
Trond Myklebust [EMAIL PROTECTED] wrote:
What about the process' capabilities? Shouldn't they also be part of a
credential?
Quite probably. The cred struct is not closed at this point. I certainly
would like to move some of the stuff hidden behind the security pointer in the
task struct, at
Trond Myklebust [EMAIL PROTECTED] wrote:
What I don't really understand is what value is gained by this exercise.
Are the savings sufficiently significant to justify the effort?
It is not about savings, but about new functionality. Basically, the
existence of reference-counted credentials
-by: David Howells [EMAIL PROTECTED]
---
include/linux/cred.h |1
include/linux/security.h | 34 +++
kernel/cred.c |7 +
security/dummy.c | 11 +
security/selinux/exports.c|6
security/selinux/hooks.c
Hi Al, Christoph, Trond, Stephen, Casey,
Here's a set of patches that implement a very basic set of COW credentials. It
compiles, links and runs for x86_64 with EXT3, (V)FAT, NFS, AFS, SELinux and
keyrings all enabled. Most other filesystems are disabled, apart from things
like proc. It is
by update_current_cred() which is
invoked on entry to any system call that might need it.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
fs/buffer.c |3 +++
fs/ioprio.c |3 +++
fs/open.c | 27 +--
fs/proc/array.c
Casey Schaufler [EMAIL PROTECTED] wrote:
Move into the cred struct the part of the task security data that defines
how a task acts upon an object. The part that defines how something acts
upon a task remains attached to the task.
This seems to me to be an unnatural and inappropriate
Andrew Morgan [EMAIL PROTECTED] wrote:
OOC If we were to simply drop support for one process changing the
capabilities of another, would we need this patch?
Well, the patch could be less, but there's still the possibility of a kernel
service wanting to override the capabilities mask.
David
-
Casey Schaufler [EMAIL PROTECTED] wrote:
Could you use object context instead of victimisation context?
It would be in better keeping with traditional security jargon.
If you wish. Personally, I find it clearer than object or subject.
The separation is necessary for a few reasons:
David Howells [EMAIL PROTECTED] wrote:
So it sounds like what you'd be happiest with would be a separate task
struct hand crafted to he the right object and subject attributes.
Actually, that whilst that is sort of feasible for CacheFiles[*], it is not
really feasible for NFSd. NFSd
Andrew Morton [EMAIL PROTECTED] wrote:
ho hum, I've seen worse-looking code ;). There's quite a bit of the usual
stuff in there: use of SPIN_LOCK_UNLOCKED, a forest of fishy-looking
volatiles
The vast majority of which are either memory-mapped hardware registers or
interrupt-routine-filled
201 - 300 of 13793 matches
Mail list logo
