PROTECTED]> wrote:
> > >
> > > >
> > > > I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the
> > > > prompt for "Default Linux Capabilities" which defaults to No:
> > > >
> > > > ---
> >
rnel. I came to the
> > > prompt for "Default Linux Capabilities" which defaults to No:
> > >
> > > ---
> > > Default Linux Capabilities (SECURITY_CAPABILITIES) [N/y/?] (NEW) ?
> > > ---
> > >
> > > However the help text recomm
On Mon, 28 Jan 2008, Matt LaPlante wrote:
> On Thu, 24 Jan 2008 19:12:01 -0600
> Matt LaPlante <[EMAIL PROTECTED]> wrote:
>
> >
> > I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the
> > prompt for "Default Linux Capabilities"
On Thu, 24 Jan 2008 19:12:01 -0600
Matt LaPlante <[EMAIL PROTECTED]> wrote:
>
> I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the prompt
> for "Default Linux Capabilities" which defaults to No:
>
> ---
> Default Linux Capabiliti
I'm doing a make oldconfig with the new 2.6.24 kernel. I came to the prompt
for "Default Linux Capabilities" which defaults to No:
---
Default Linux Capabilities (SECURITY_CAPABILITIES) [N/y/?] (NEW) ?
---
However the help text recommends saying Yes.
---
This enables the
On Aug 9, 2005, at 11:16:33, Christopher Warner wrote:
In my observer pragmatic view; yes. On many occasion, i've come to CAP
calls only to be frustrated with the sheer disconnect of it all. It
simply doesn't work. If it means having to break posix conformance
for a
working implementation. The
In my observer pragmatic view; yes. On many occasion, i've come to CAP
calls only to be frustrated with the sheer disconnect of it all. It
simply doesn't work. If it means having to break posix conformance for a
working implementation. Then so be it.
-- Christopher Warner
On Tue, 2005-08-09 at 00
Hello,
Ts'o wrote:
>since _obviously_ when root calls setuid(), it never fails, right?
Well this really depends on how privileged a certain root user (think of
SELinux and others) is.
>(2) There was some debate about whether or not this method was the
>
course of wisdom,
James M
On Tue, 9 Aug 2005, David Madore wrote:
> the "process management" part. For example, I might like to run this
> or that binary, which claims it needs to be run as root, with a
> limited set of capabilities: the current Linux kernels make this quite
> impossible.
Not impossible with SELinux.
-
On Tue, Aug 09, 2005 at 01:53:50AM +, Theodore Ts'o wrote:
> The POSIX specification for capabilities requires filesystem support,
> so that each executables can be marked with three capability sets ---
> which indicate which capabilities are asserted when the executable
> starts, which capabil
Let me play the Devil's advocate here.
Should we be thinking about deprecating and removing capabilities from
Linux?
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Mon, Aug 08, 2005 at 11:53:33PM +, David Wagner wrote:
> David Madore wrote:
> >This does not tell me, then, why CAP_SETPCAP was globally disabled by
> >default, nor why passing of capabilities across execve() was entirely
> >removed instead of being fixed.
>
> I do not know of any good re
David Madore wrote:
>This does not tell me, then, why CAP_SETPCAP was globally disabled by
>default, nor why passing of capabilities across execve() was entirely
>removed instead of being fixed.
I do not know of any good reason. Perhaps the few folks who knew enough
to fix it properly didn't fee
Sorry for replying to myself...
On Mon, Aug 08, 2005 at 09:13:06PM +, David Madore wrote:
> However, what I do not understand is precisely _how_ one gets a
> sendmail process without CAP_SETUID: for that is the heart of the
> problem, and that is where the bug really was. But [#3] and [#4] ar
to restore working capabilities. However, the matter
seems rather complicted and I would like to understand the full story.
Hours of Google-grepping through the lkml archives has not helped me
very much, so I hope someone can get the history straight.
I understand that Linux capabilities first
jnf <[EMAIL PROTECTED]> writes:
> Thank you, when I get a second I will take a look through it. I've already
> written a couple programs to set/get capabilities, so I am aware of the
> interface/api, it was just that even with the capabilities it was not
> working ;]
> Either way I will take a loo
* jnf ([EMAIL PROTECTED]) wrote:
> I will read the paper before commenting on it further, however I cannot
> see what dangers it would really provide that a setuid program doesnt
> already have- other than the ability to give another non-root process root
> like abilities. However, the more I ponde
Hi Chris, thank you for the response.
>
> This is not exactly safe. It was removed on purpose. See this paper:
> http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
I will read the paper before commenting on it further, however I cannot
see what dangers it would really provide that a set
* jnf ([EMAIL PROTECTED]) wrote:
> I have been playing a little here and there with linux capabilities, and
> seem to be hitting a few snags so I was hoping to obtain some input on
> their current status. The kernel on the box in question is 2.6.10, with
> the CAP_INIT_EFF_SET macro
Hi.
I have been playing a little here and there with linux capabilities, and
seem to be hitting a few snags so I was hoping to obtain some input on
their current status. The kernel on the box in question is 2.6.10, with
the CAP_INIT_EFF_SET macro modified to allow init to have CAP_SETPCAP.
I am
20 matches
Mail list logo
