LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: serge@hallyn.com
Cc: ebiederm@xmission.com, hpa@zytor.com, miklos@szeredi.hu,
	akpm@linux-foundation.org, viro@ftp.linux.org.uk,
	linuxram@us.ibm.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, containers@lists.osdl.org,
	linux-security-module@vger.kernel.org
Subject: Re: [patch] unprivileged mounts update
Date: Wed, 25 Apr 2007 21:33:43 +0200	[thread overview]
Message-ID: <E1HgnFH-0006gR-00@dorka.pomaz.szeredi.hu> (raw)
In-Reply-To: <20070425185244.GA20688@vino.hallyn.com> (serge@hallyn.com)

> Right, I figure if the normal action is to always do
> mnt->user = current->fsuid, then for the special case we
> pass a uid in someplace.  Of course...  do we not have a
> place to do that?  Would it be a no-no to use 'data' for
> a non-fs-specific arg?

I guess it would be OK for bind, but not for new- and remounts, where
'data' is already used.

Maybe it's best to stay with fsuid after all, and live with having to
restore capabilities.  It's not so bad after all, this seems to do the
trick:

	cap_t cap = cap_get_proc();
	setfsuid(uid);
	cap_set_proc(cap);

Unfortunately these functions are not in libc, but in a separate
"libcap" library.  Ugh.

Miklos

  reply	other threads:[~2007-04-25 19:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-25  7:45 Miklos Szeredi
2007-04-25 15:18 ` Miklos Szeredi
2007-04-25 16:55   ` H. Peter Anvin
2007-04-25 17:20     ` Serge E. Hallyn
2007-04-25 17:46       ` Eric W. Biederman
2007-04-25 17:56         ` Serge E. Hallyn
2007-04-25 18:41           ` Eric W. Biederman
2007-04-25 18:52             ` Serge E. Hallyn
2007-04-25 19:33               ` Miklos Szeredi [this message]
2007-04-26 14:57                 ` Serge E. Hallyn
2007-04-26 15:23                   ` Miklos Szeredi
2007-04-26 16:19                     ` Serge E. Hallyn
2007-04-26 16:29                       ` Miklos Szeredi
2007-04-26 19:42                         ` Serge E. Hallyn
2007-04-26 19:56                           ` Miklos Szeredi
2007-04-27  2:10                             ` Serge E. Hallyn
2007-04-25 17:21   ` Eric W. Biederman
2007-04-25 17:30     ` Serge E. Hallyn
2007-04-26 19:10     ` Jan Engelhardt
2007-04-26 20:27       ` Miklos Szeredi
2007-04-27  4:10         ` Eric W. Biederman
2007-04-27  7:01         ` Jan Engelhardt
2007-04-25 19:33   ` Andrew Morton
2007-04-25 19:45     ` Miklos Szeredi

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=E1HgnFH-0006gR-00@dorka.pomaz.szeredi.hu \
    --to=miklos@szeredi.hu \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=serge@hallyn.com \
    --cc=viro@ftp.linux.org.uk \
    --subject='Re: [patch] unprivileged mounts update' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).