On 04/12/16 11:12, Linus Torvalds wrote:
So what I want to happen is to "just make /dev/ptmx work". Get rid of
the broken "single instance" crap. The only reason it exists is
exactly because /dev/ptmx does not work.
I think the current situation is completely and utterly broken. We
should neve
On Tue, Apr 12, 2016 at 10:44 AM, Andy Lutomirski wrote:
> Linus, you said that people who want to protect their pts should deny
> execute. So I set it up:
>
> # ls -l
> total 0
> crw---. 1 root root 5, 2 Apr 12 10:38 ptmx
> drwx--. 2 root root0 Apr 2 11:35 pts
No you didn't. You're
On Mon, Apr 11, 2016 at 1:12 PM, Andy Lutomirski wrote:
> On Sat, Apr 9, 2016 at 6:27 PM, Linus Torvalds
> wrote:
>>
>> On Apr 9, 2016 5:45 PM, "Andy Lutomirski" wrote:
>>>
>>>
>>> What we *do* want to do, though, is to prevent the following:
>>
>> I don't see the point. Why do you bring up this
Al Viro writes:
> On Mon, Apr 11, 2016 at 07:10:47PM -0500, Eric W. Biederman wrote:
>> Actually for me this is about keeping the semantics simpler, and coming
>> up with a higher performance implementation.
>>
>> A dentry that does an automount is already well defined.
>>
>> Making the rule th
On Mon, Apr 11, 2016 at 08:23:00PM -0500, Eric W. Biederman wrote:
> Perhaps I am reading the code wrong but as I read it that information is
> simply not available in get_super.
Correct. For a very good reason - the same superblock can bloody well end up
in many places; having it tied to _the_
On Mon, Apr 11, 2016 at 07:10:47PM -0500, Eric W. Biederman wrote:
> Actually for me this is about keeping the semantics simpler, and coming
> up with a higher performance implementation.
>
> A dentry that does an automount is already well defined.
>
> Making the rule that accessing /dev/ptmx cau
"H. Peter Anvin" writes:
> On April 11, 2016 5:10:47 PM PDT, ebied...@xmission.com wrote:
>>Linus Torvalds writes:
>>
>>> On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman
>>> wrote:
My practical concern if we worked through the implementation details
would be how would it inter
On Mon, Apr 11, 2016 at 07:48:28AM -0700, H. Peter Anvin wrote:
> Here is an entire different approach, I don't know if it is sane or not: when
> *mounting* the devpts filesystem, it could automagically create the bins
> mount for ptmx in the parent of its mount point. Presumably the would be
On Mon, Apr 11, 2016 at 6:06 PM, H. Peter Anvin wrote:
>
> Why bother with an automount? You can look up ../ptmx from the devpts
> get_super method and just do the bind mount once. No fuss, no muss. What's
> wrong with that?
Ehh. What if somebody wants to mount the same devpts in multiple
pl
On April 11, 2016 5:10:47 PM PDT, ebied...@xmission.com wrote:
>Linus Torvalds writes:
>
>> On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman
>> wrote:
>>>
>>> My practical concern if we worked through the implementation details
>>> would be how would it interact with people who bind mount
>/dev
On Mon, Apr 11, 2016 at 5:22 PM, Eric W. Biederman
wrote:
>
> I meant the one where I conceded that the only think that it could
> possible protect against was a denial of service attack, from which we
> probably don't care.
Yeah, that's the same email I was talking about, I was just quoting
anot
Linus Torvalds writes:
> On Mon, Apr 11, 2016 at 4:49 PM, Eric W. Biederman
> wrote:
>>
>> I replied earlier. Did you not see my reply?
>
>
> Are you talking about the one where you agreed that the scenario was
> made up and insane? The one where you said that you're worried about
> breaking ou
Linus Torvalds writes:
> On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman
> wrote:
>>
>> My practical concern if we worked through the implementation details
>> would be how would it interact with people who bind mount /dev/pts/ptmx
>> on top of /dev/ptmx. We might get some strange new errors
On Mon, Apr 11, 2016 at 4:49 PM, Eric W. Biederman
wrote:
>
> I replied earlier. Did you not see my reply?
Are you talking about the one where you agreed that the scenario was
made up and insane? The one where you said that you're worried about
breaking out "extension" where ptmx is non-0666?
T
On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman
wrote:
>
> My practical concern if we worked through the implementation details
> would be how would it interact with people who bind mount /dev/pts/ptmx
> on top of /dev/ptmx. We might get some strange new errors.
Yes, please don't let's play "
Linus Torvalds writes:
> On Apr 9, 2016 5:45 PM, "Andy Lutomirski" wrote:
>>
>>
>> What we *do* want to do, though, is to prevent the following:
>
> I don't see the point. Why do you bring up this insane scenario that
> nobody can possibly care about?
>
> So you actually have any reason to belie
"H. Peter Anvin" writes:
> On April 11, 2016 1:12:22 PM PDT, Andy Lutomirski wrote:
>>On Sat, Apr 9, 2016 at 6:27 PM, Linus Torvalds
>> wrote:
>>>
>>> On Apr 9, 2016 5:45 PM, "Andy Lutomirski"
>>wrote:
What we *do* want to do, though, is to prevent the following:
>>>
>>> I don't
On April 11, 2016 1:12:22 PM PDT, Andy Lutomirski wrote:
>On Sat, Apr 9, 2016 at 6:27 PM, Linus Torvalds
> wrote:
>>
>> On Apr 9, 2016 5:45 PM, "Andy Lutomirski"
>wrote:
>>>
>>>
>>> What we *do* want to do, though, is to prevent the following:
>>
>> I don't see the point. Why do you bring up this
Andy Lutomirski writes:
> On Sat, Apr 9, 2016 at 6:27 PM, Linus Torvalds
> wrote:
>>
>> On Apr 9, 2016 5:45 PM, "Andy Lutomirski" wrote:
>>>
>>>
>>> What we *do* want to do, though, is to prevent the following:
>>
>> I don't see the point. Why do you bring up this insane scenario that nobody
>>
Linus Torvalds writes:
> On Sat, Apr 9, 2016 at 3:37 PM, H. Peter Anvin wrote:
>>
>> On the flipside, if we were to allow ourselves to break userspace, at this
>> point I would suggest making /dev/pts/ptmx have a different device number
>> and make the legacy /dev/ptmx print a warning message,
On Sat, Apr 9, 2016 at 6:27 PM, Linus Torvalds
wrote:
>
> On Apr 9, 2016 5:45 PM, "Andy Lutomirski" wrote:
>>
>>
>> What we *do* want to do, though, is to prevent the following:
>
> I don't see the point. Why do you bring up this insane scenario that nobody
> can possibly care about?
>
> So you a
On April 9, 2016 6:27:36 PM PDT, Linus Torvalds
wrote:
>On Apr 9, 2016 5:45 PM, "Andy Lutomirski" wrote:
>>
>>
>> What we *do* want to do, though, is to prevent the following:
>
>I don't see the point. Why do you bring up this insane scenario that
>nobody
>can possibly care about?
>
>So you actu
On Sat, Apr 9, 2016 at 5:16 PM, Linus Torvalds
wrote:
> On Sat, Apr 9, 2016 at 5:06 PM, H. Peter Anvin wrote:
>>
>> Fixing the default permissions is trivial, of course. The intent from the
>> beginning was to make a ptmx -> pts/ptmx, but user space never did...
>
> That wasn't my point.
>
> Be
On Sat, Apr 9, 2016 at 5:06 PM, H. Peter Anvin wrote:
>
> Fixing the default permissions is trivial, of course. The intent from the
> beginning was to make a ptmx -> pts/ptmx, but user space never did...
That wasn't my point.
Because the permissions have never been usable, I pretty much
guaran
On April 9, 2016 5:01:27 PM PDT, Linus Torvalds
wrote:
>On Sat, Apr 9, 2016 at 3:37 PM, H. Peter Anvin wrote:
>>
>> On the flipside, if we were to allow ourselves to break userspace, at
>this point I would suggest making /dev/pts/ptmx have a different device
>number and make the legacy /dev/ptmx
On Sat, Apr 9, 2016 at 3:37 PM, H. Peter Anvin wrote:
>
> On the flipside, if we were to allow ourselves to break userspace, at this
> point I would suggest making /dev/pts/ptmx have a different device number and
> make the legacy /dev/ptmx print a warning message, after which it can at
> least
On April 9, 2016 7:45:46 AM PDT, ebied...@xmission.com wrote:
>"H. Peter Anvin" writes:
>
>> On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes
> wrote:
>>>
If anyone has a better idea on how userspace should connect the
>>>master
pty file descriptor the slave file descriptor, I would
"H. Peter Anvin" writes:
> On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes
> wrote:
>>
>>> If anyone has a better idea on how userspace should connect the
>>master
>>> pty file descriptor the slave file descriptor, I would be willing to
>>> implement that instead.
>>
>>If we are willing to
On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes
wrote:
>
>> If anyone has a better idea on how userspace should connect the
>master
>> pty file descriptor the slave file descriptor, I would be willing to
>> implement that instead.
>
>If we are willing to go away from the existing mess of a t
> If anyone has a better idea on how userspace should connect the master
> pty file descriptor the slave file descriptor, I would be willing to
> implement that instead.
If we are willing to go away from the existing mess of a tty interface
inflicted on us by BSD and then mashed up by POSIX then
Linus Torvalds writes:
> But more fundamentally I still don't actually understand why you even
> really care.
At this point I care because there is a failure of communication.
Until this email no one has ever said: "Ok that actually could happen
but we don't actually care."
Right now I am a bi
On Fri, Apr 8, 2016 at 2:29 PM, Eric W. Biederman wrote:
> Andy Lutomirski writes:
>
>> On Apr 8, 2016 12:05 PM, "Linus Torvalds"
>> wrote:
>>>
>>> On Fri, Apr 8, 2016 at 11:51 AM, Eric W. Biederman
>>> wrote:
>>> >
>>> > Given that concern under the rule we don't break userspace we have to
>>
On Fri, Apr 8, 2016 at 2:29 PM, Eric W. Biederman wrote:
>
> I don't think so. For one it depends on getting s_user_ns which should
> happen but is not there yet. For another the way you describe
> it you would break the case of
>
> unshare(CLONE_NEWUSER);
> unshare(CLONE_NEWNS);
Andy Lutomirski writes:
> On Apr 8, 2016 12:05 PM, "Linus Torvalds"
> wrote:
>>
>> On Fri, Apr 8, 2016 at 11:51 AM, Eric W. Biederman
>> wrote:
>> >
>> > Given that concern under the rule we don't break userspace we have to
>> > check the permissions of /dev/pts/ptmx when we are creating a new
On Apr 8, 2016 12:05 PM, "Linus Torvalds" wrote:
>
> On Fri, Apr 8, 2016 at 11:51 AM, Eric W. Biederman
> wrote:
> >
> > Given that concern under the rule we don't break userspace we have to
> > check the permissions of /dev/pts/ptmx when we are creating a new pty,
> > on a instance of devpts tha
Linus Torvalds writes:
> On Fri, Apr 8, 2016 at 11:51 AM, Eric W. Biederman
> wrote:
>>
>> Given that concern under the rule we don't break userspace we have to
>> check the permissions of /dev/pts/ptmx when we are creating a new pty,
>> on a instance of devpts that was created with newinstance.
On Fri, Apr 8, 2016 at 11:51 AM, Eric W. Biederman
wrote:
>
> Given that concern under the rule we don't break userspace we have to
> check the permissions of /dev/pts/ptmx when we are creating a new pty,
> on a instance of devpts that was created with newinstance.
The rule is that we don't break
Al Viro writes:
> On Tue, Apr 05, 2016 at 03:54:25AM +0100, Al Viro wrote:
>
>> That, I take it, is a lookup for .. and buggering off if it fails *or* if
>> we had been in caller's root or something that overmount it? Not that the
>> latter had been possible - root is a directory and can be over
Linus Torvalds writes:
> On Mon, Apr 4, 2016 at 6:29 PM, Eric W. Biederman
> wrote:
>>
>> In practice I expect the permission checks are a non-issue as the
>> permissions on /dev/ptmx and /dev/pts/ptmx are always 0666.
>
> So I think this is still entirely wrongheaded, and thinking about the
>
On Mon, Apr 4, 2016 at 6:29 PM, Eric W. Biederman wrote:
>
> In practice I expect the permission checks are a non-issue as the
> permissions on /dev/ptmx and /dev/pts/ptmx are always 0666.
So I think this is still entirely wrongheaded, and thinking about the
problem the wrong way around.
The iss
On Tue, Apr 05, 2016 at 03:54:25AM +0100, Al Viro wrote:
> That, I take it, is a lookup for .. and buggering off if it fails *or* if
> we had been in caller's root or something that overmount it? Not that the
> latter had been possible - root is a directory and can be overmounted only
> by anothe
On Mon, Apr 04, 2016 at 08:29:17PM -0500, Eric W. Biederman wrote:
> +#ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
> +static int devpts_path_ptmx(struct file *filp)
> +{
> + struct pts_fs_info *fsi;
> + struct path root, path;
> + struct dentry *old;
> + int err = -ENOENT;
> + int r
This is in preparation for forcing each mount of devpts to be a
distinct filesystem. The goal of this change is to have as few user
visible changes from the kernel today as possible.
On each open of /dev/ptmx look at the relative path pts and see if
devpts is mounted there.
If the filesystem fou
43 matches
Mail list logo
