Fourth attempt at a shared credentials patch

1. Allow tasks to share credentials

I worry about the lack of locking here.

Maybe it's the right thing to do, I don't really know.

But I _know_, for example, that this is just a horrid security hole the
way it is now - the execve() path doesn't create a unique "cred"
structure, so if you execve() a suid binary from a CLONE_CRED thread, the
other threads get the suid'ness and can do whatever they want.

At the very least, it should disallow suid exec's when

        atomic_read(&current->cred->count) > 1

which is the same approach we do wrt other shared state (ie disallow a
CLONE_FILES thing from doing a suid execve etc).

The alternative is to just allocate a new cred structure on execve.

As-is this patch is way way too dangerous. You can trivially create a root
hole by doing

        if (!clone(CLONE_CRED)) {
                execve("su");
                exit(1);
        }

        ..this thread now also got root..

You may be right. I don't see any huge reason for it, but see above on
other fundamental problems.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Perl 4.034

3. PATCH: BSD-style credentials for Linux 2.5.0-pre6...

4. memory, sig 11, and other fun things

5. shared credentials with vfs snapshotting

6. Running sz?

7. PATCH: Four function buttons on DELL Latitude X200

8. Welcome to the comp.os.linux.* hierarchy!

9. four ide drives on single controller - need patches

10. newbie attempting file sharing with serial cable

11. [PATCH] ReiserFS Attempt 3: fix reiserfs memleaks on journal opening failures in 2.5.64

12. M$ makes an ATTEMPT at patching Outlook

13. "tcpdev is corrupt" while attempting to patch