public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Waechtler <peter@helios.de>
To: Peter Waechtler <pwaechtler@mac.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] core not owned by euid, mm->dumpable
Date: Mon, 5 Apr 2004 13:51:57 +0200	[thread overview]
Message-ID: <200404051351.57667.peter@helios.de> (raw)
In-Reply-To: <16293307.1081153633839.JavaMail.pwaechtler@mac.com>

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

Am Montag, 5. April 2004 10:27 schrieb Peter Waechtler:
> With the current behavior typical server programs that switch euid
> don't dump core. This is done "for security".
> If the core file pattern exists the dump is written to but readable
> for the file owner (not necessarily root - don't argue: only chdir into
> dirs that only root can write to: think of file servers like samba)
>
> The patch below addresses this (but still not perfect).
> What I would like to see: instead of mm->dumpable=0 when calling seteuid()
> something like mm->dumpAs=root and making sure that the core is owned by
> root mode 600
>
> I could install a sighandler that calls prctl(PR_SET_DUMPABLE,1,0,0,0),
> switch euid to root, but still the formerly placed core is owned by evil
> user :(
> Then I could read the core pattern and unlink such a file - and all this
> just for the Linux platform...
>

Unlink a previously existing core.
I tried on solaris - I find the behavior (tunable with coreadm) perfect:
Switched uid? -> create as root (unlink a previously and potentially opened
core first: yes it got a new inode) then creat(O_EXCL,0600)


[-- Attachment #2: linux-core.patch --]
[-- Type: text/x-diff, Size: 2723 bytes --]

--- fs/namei.c.orig	2004-04-05 13:44:30.317084264 +0200
+++ fs/namei.c	2004-04-05 13:45:40.668389240 +0200
@@ -1694,24 +1694,13 @@
 	return error;
 }
 
-/*
- * Make sure that the actual truncation of the file will occur outside its
- * directory's i_sem.  Truncate can take a long time if there is a lot of
- * writeout happening, and we don't want to prevent access to the directory
- * while waiting on the I/O.
- */
-asmlinkage long sys_unlink(const char __user * pathname)
+int do_unlink(char *name)
 {
 	int error = 0;
-	char * name;
 	struct dentry *dentry;
 	struct nameidata nd;
 	struct inode *inode = NULL;
 
-	name = getname(pathname);
-	if(IS_ERR(name))
-		return PTR_ERR(name);
-
 	error = path_lookup(name, LOOKUP_PARENT, &nd);
 	if (error)
 		goto exit;
@@ -1736,8 +1725,6 @@
 exit1:
 	path_release(&nd);
 exit:
-	putname(name);
-
 	if (inode)
 		iput(inode);	/* truncate the inode here */
 	return error;
@@ -1748,6 +1735,25 @@
 	goto exit2;
 }
 
+/*
+ * Make sure that the actual truncation of the file will occur outside its
+ * directory's i_sem.  Truncate can take a long time if there is a lot of
+ * writeout happening, and we don't want to prevent access to the directory
+ * while waiting on the I/O.
+ */
+asmlinkage long sys_unlink(const char __user * pathname)
+{
+	char * name;
+
+	name = getname(pathname);
+	if(IS_ERR(name))
+		return PTR_ERR(name);
+
+	error = do_unlink(name);
+	putname(name);
+	return error;
+}
+
 int vfs_symlink(struct inode *dir, struct dentry *dentry, const char *oldname)
 {
 	int error = may_create(dir, dentry, NULL);
--- fs/exec.c.orig	2004-04-05 09:41:31.134456912 +0200
+++ fs/exec.c	2004-04-05 13:50:17.093366256 +0200
@@ -1387,9 +1387,14 @@
 		goto fail_unlock;
 
  	format_corename(corename, core_pattern, signr);
-	file = filp_open(corename, O_CREAT | 2 | O_NOFOLLOW | O_LARGEFILE, 0600);
-	if (IS_ERR(file))
-		goto fail_unlock;
+	file = filp_open(corename, O_CREAT | O_EXCL | 2 | O_NOFOLLOW | O_LARGEFILE, 0600);
+	if (IS_ERR(file)){
+		if (do_unlink(corename))
+			goto fail_unlock;
+		file = filp_open(corename, O_CREAT | O_EXCL | 2 | O_NOFOLLOW | O_LARGEFILE, 0600);
+		if (IS_ERR(file))
+			goto fail_unlock;
+	}
 	inode = file->f_dentry->d_inode;
 	if (inode->i_nlink > 1)
 		goto close_fail;	/* multiple links - don't dump */
--- include/linux/fs.h.orig	2004-04-05 09:42:52.205132296 +0200
+++ include/linux/fs.h	2004-04-05 13:50:46.119953544 +0200
@@ -1253,6 +1253,7 @@
 
 extern int open_namei(const char *, int, int, struct nameidata *);
 extern int may_open(struct nameidata *, int, int);
+extern int do_unlink(char *);
 
 extern int kernel_read(struct file *, unsigned long, char *, unsigned long);
 extern struct file * open_exec(const char *);

      reply	other threads:[~2004-04-05 11:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-05  8:27 [PATCH RFC] core not owned by euid, mm->dumpable Peter Waechtler
2004-04-05 11:51 ` Peter Waechtler [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200404051351.57667.peter@helios.de \
    --to=peter@helios.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pwaechtler@mac.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox