sn't have kernel support
for thread level creds and *bsd.org doesn't want to do it, we just do what fits
today's requirements and what Linux is capable of,
Jim
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
"If ease of use was the only requirement, we would all be riding tri
, today's multi-client workloads. If that means extensions to
POSIX fine. But if POSIX gets hung up because *BSD doesn't have kernel support
for thread level creds and *bsd.org doesn't want to do it, we just do what fits
today's requirements and what Linux is capable of,
Jim
--
Jim Lieb
Linux
---
> -- Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.n
://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
If ease of use was the only requirement, we would all be riding tricycles
- Douglas Engelbart 1925–2013
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thursday, March 27, 2014 12:45:30 Andy Lutomirski wrote:
> On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb wrote:
> > Rather than inline, I'm responding in the context of Jeremy's comments but
> > I have to answer others as well. It is Jeremy after all who said my ba
o get the
> close-on-exec semantics and the fact that the creds are
> already hung off the fd's in kernel space.
>
> I'd rather any creads call use a different type, even if
> it's a typedef of 'int -> creds_handle_t', just to make
> it really clear it's *NOT* an fd.
>
>
.
That way we can also make it clear this thing only has
meaning to a thread group, and SHOULD NOT (and indeed
preferably CAN NOT) be passed between processes.
Cheers,
Jeremy.
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
If ease of use was the only requirement, we would all
On Thursday, March 27, 2014 12:45:30 Andy Lutomirski wrote:
On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb jl...@panasas.com wrote:
Rather than inline, I'm responding in the context of Jeremy's comments but
I have to answer others as well. It is Jeremy after all who said my baby
was ugly
On Saturday, November 02, 2013 01:07:59 Tetsuo Handa wrote:
> Jim Lieb wrote:
> > On Friday, November 01, 2013 22:24:12 Tetsuo Handa wrote:
> > > Jim Lieb wrote:
> > > > Subsequent uses look like:
> > > > use_creds(cached fd);
> > > &
On Friday, November 01, 2013 22:24:12 Tetsuo Handa wrote:
> Jim Lieb wrote:
> > Subsequent uses look like:
> > use_creds(cached fd);
> >
> > followed by
> >
> > open/creat/mknod/write
> >
> > followed by
> >
> >
On Friday, November 01, 2013 22:24:12 Tetsuo Handa wrote:
Jim Lieb wrote:
Subsequent uses look like:
use_creds(cached fd);
followed by
open/creat/mknod/write
followed by
use_creds(-1);
Are you aware that calling commit_creds() is prohibitted between
On Saturday, November 02, 2013 01:07:59 Tetsuo Handa wrote:
Jim Lieb wrote:
On Friday, November 01, 2013 22:24:12 Tetsuo Handa wrote:
Jim Lieb wrote:
Subsequent uses look like:
use_creds(cached fd);
followed by
open/creat/mknod/write
On Thursday, October 31, 2013 12:48:54 Andy Lutomirski wrote:
> On Thu, Oct 31, 2013 at 12:43 PM, Jim Lieb wrote:
> > On Thursday, October 31, 2013 12:09:08 Andy Lutomirski wrote:
> >> On Thu, Oct 24, 2013 at 1:24 PM, Jim Lieb wrote:
> >> > On Thursday, October 24,
On Thursday, October 31, 2013 12:09:08 Andy Lutomirski wrote:
> On Thu, Oct 24, 2013 at 1:24 PM, Jim Lieb wrote:
> > On Thursday, October 24, 2013 12:28:15 Andy Lutomirski wrote:
> >> On Wed, Oct 23, 2013 at 10:59 PM, Eric W. Biederman
> >>
> >> w
On Thursday, October 31, 2013 12:09:08 Andy Lutomirski wrote:
On Thu, Oct 24, 2013 at 1:24 PM, Jim Lieb jl...@panasas.com wrote:
On Thursday, October 24, 2013 12:28:15 Andy Lutomirski wrote:
On Wed, Oct 23, 2013 at 10:59 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Andy
On Thursday, October 31, 2013 12:48:54 Andy Lutomirski wrote:
On Thu, Oct 31, 2013 at 12:43 PM, Jim Lieb jl...@panasas.com wrote:
On Thursday, October 31, 2013 12:09:08 Andy Lutomirski wrote:
On Thu, Oct 24, 2013 at 1:24 PM, Jim Lieb jl...@panasas.com wrote:
On Thursday, October 24, 2013
t still applies here. It is
identification but only for within the same kernel. As for namespaces, the
translation was done when the creds fd was created. I suppose if it was
passed across namespace boundaries there could be a problem but what is in the
creds structure is the translated fduid
y field in
> the cred except for uids and gids.
Yes. Which is why in my original patch I pass a user_creds structure that
only has the fsuid, fsgid, and altgroups. This means that the caller can
*only* impersonate these particular creds for purposes of file access, not priv
escalation.
As fo
is also opened with O_CLOEXEC so children don't get it. Our use case doesn't
need to fork/exec and if we needed to, we wouldn't be using switch_creds for
it anyway. Adding Close-on-exec removes the exploit opportunity.
Jim
Eric
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
If ease
to prevent you from being root as well. Also, since these are
O_CLOEXEC and switch_creds magic fds, this can't happen because the fd is
gone post-exec.
--Andy
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
If ease of use was the only requirement, we would all be riding tricycles
check because
all that can happen is to return to the immutable real set. Also, I don't
need the initial open of /dev/null.
Does this fit?
Jim
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
"If ease of use was the only requirement, we would all be riding tricycles"
- Douglas Engelba
This is temporary number awaiting syscall number assignment.
Signed-off-by: Jim Lieb
---
arch/x86/syscalls/syscall_32.tbl | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
index aabfb83..b836839 100644
--- a/arch/x86/syscalls
ly
dependent in this syscall so when appropriate, numbers can be assigned.
Please review and comment to me. The code fragments above are from my
test program.
Regards,
Jim Lieb
NFS Ganesha project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
for subsequent operations for that client more efficient.
Signed-off-by: Jim Lieb
---
include/linux/cred.h | 15
include/linux/syscalls.h | 2 +
kernel/sys.c | 175 +++
kernel/sys_ni.c | 3 +
4 files changed, 195 insertions
This is a temporary while waiting for syscall number assignment.
Signed-off-by: Jim Lieb
---
arch/x86/syscalls/syscall_64.tbl | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
index 38ae65d..f46b75c 100644
--- a/arch/x86
for subsequent operations for that client more efficient.
Signed-off-by: Jim Lieb jl...@panasas.com
---
include/linux/cred.h | 15
include/linux/syscalls.h | 2 +
kernel/sys.c | 175 +++
kernel/sys_ni.c | 3 +
4 files changed
This is temporary number awaiting syscall number assignment.
Signed-off-by: Jim Lieb jl...@panasas.com
---
arch/x86/syscalls/syscall_32.tbl | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
index aabfb83..b836839 100644
and comment to me. The code fragments above are from my
test program.
Regards,
Jim Lieb
NFS Ganesha project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
This is a temporary while waiting for syscall number assignment.
Signed-off-by: Jim Lieb jl...@panasas.com
---
arch/x86/syscalls/syscall_64.tbl | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
index 38ae65d..f46b75c 100644
don't
need the initial open of /dev/null.
Does this fit?
Jim
--
Jim Lieb
Linux Systems Engineer
Panasas Inc.
If ease of use was the only requirement, we would all be riding tricycles
- Douglas Engelbart 1925–2013
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
30 matches
Mail list logo
