All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janak Desai <janak@us.ibm.com>
To: serue@us.ibm.com
Cc: Florian Weimer <fw@deneb.enyo.de>,
	viro@parcelfarce.linux.theplanet.co.uk, sds@tycho.nsa.gov,
	linuxram@us.ibm.com, ericvh@gmail.com, dwalsh@redhat.com,
	jmorris@redhat.com, akpm@osdl.org, torvalds@osdl.org,
	gh@us.ibm.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] New system call, unshare
Date: Wed, 10 Aug 2005 11:05:47 -0400	[thread overview]
Message-ID: <42FA17CB.1020702@us.ibm.com> (raw)
In-Reply-To: <20050810141849.GA5639@serge.austin.ibm.com>

serue@us.ibm.com wrote:
> Quoting Florian Weimer (fw@deneb.enyo.de):
> 
>>* Janak Desai:
>>
>>
>>>With unshare, namespace setup can be done using PAM session
>>>management functions without patching individual commands.
>>
>>I don't think it's a good idea to use security-critical code well
> 
> 
> Note that this patch is not removing the CAP_SYS_ADMIN requirement,
> just allowing the operation to happen outside of clone().  Unlike
> domain transitions in selinux, which should be tied to exec() so
> as to tie them to known code, I don't see what clone() would provide
> in terms of safety which we are losing.
> 
> 
>>without its original specification.  Clearly the current situation
>>sucks, but this is mainly a lack of PAM functionality, IMHO.
> 
> 
> I'm not sure this is to do with PAM functionality, rather than
> just its design.  Is there a way of "fixing" pam so that we don't
> need unshare()?
> 

I have been trying to narrow down the problem since Alan's post
about using clone() instead of unshare. The problem comes down to
parent, on _exit(), clobbering controlling tty. I have tried, from
the child, to close and open the tty stored in PAM but that has
not helped.

-Janak


  reply	other threads:[~2005-08-10 15:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-08 13:28 [PATCH 0/3] New system call, unshare Janak Desai
2005-08-10 14:08 ` Florian Weimer
2005-08-10 14:18   ` serue
2005-08-10 15:05     ` Janak Desai [this message]
2005-08-23  6:18   ` Al Viro
2005-09-07 17:34     ` Janak Desai

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=42FA17CB.1020702@us.ibm.com \
    --to=janak@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=dwalsh@redhat.com \
    --cc=ericvh@gmail.com \
    --cc=fw@deneb.enyo.de \
    --cc=gh@us.ibm.com \
    --cc=jmorris@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=sds@tycho.nsa.gov \
    --cc=serue@us.ibm.com \
    --cc=torvalds@osdl.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.