[QA] Failures for 2005.06.05

[Marc E. Fiuczynski]

Our util-vserver is ancient.  It could well be that a newer version contains
a setattr that uses the syscall vs. the ioctl.

> -----Original Message-----
> From: qa-bounces at planet-lab.org [mailto:qa-bounces at planet-lab.org]On
> Behalf Of Steve Muir
> Sent: Sunday, June 05, 2005 10:58 PM
> To: Marc E. Fiuczynski
> Cc: qa at lists.planet-lab.org
> Subject: RE: [QA] Failures for 2005.06.05
>
>
> one of the many great non-backwards compatible changes made in
> the vserver
> code at some point was to prevent modification of certain file attributes
> e.g., the linkage-invert bit, perhaps also the barrier bit, by using an
> ioctl (this was the change to the set of user-modifiable bits) - instead
> you have to use a special vserver system call, which ignores those bits.
> i thought setattr used the syscall rather than the ioctl, but strace on
> alice shows that it just uses an ioctl.  at this point i'm kinda
> confused,
> i'll have to look into it more tomorrow.
>
>
>
> On Sun, 5 Jun 2005, Marc E. Fiuczynski wrote:
>
> > Hi Steve,
> >
> > It appears that setattr --barrier /vservers does not set the appropriate
> > bits.  Looks like I screwed up the mask of the user-modifiable bits in
> > include/linux/ext2_fs.h back on Jan 21st. It's odd that prior QA tests
> > didn't catch this, considering that it apparently was broken for a long
> > time.
> >
> > Marc
> >
> >
> >
> >> -----Original Message-----
> >> From: Steve Muir [mailto:smuir at CS.Princeton.EDU]
> >> Sent: Sunday, June 05, 2005 11:04 AM
> >> To: Marc E. Fiuczynski
> >> Subject: RE: [QA] Failures for 2005.06.05
> >>
> >>
> >> the thing we'ret trying to prevent is the standard 'chroot twice'
> >> exploit,
> >> which we accomplish by setting a 'barrier' bit on the /vservers
> >> directory.
> >> the kernel prevents any processes not in the root context from
> accessing
> >> directories with the barrier bit set - see first
> IS_BARRIER(inode) check
> >> in permission() in fs/namei.c.  so a) in your note would be the barrier
> >> check being omitted from the kernel, and b) would be the barrier bit
> >> not being set - those are indeed the most likely problems.  it
> looks like
> >> the barrier bit is not set on alice:
> >>
> >> [root at alice root]# /usr/lib/util-vserver/showattr /vservers
> >> /vservers       00000000
> >>
> >> this is the output on a production node:
> >>
> >> [root at planetlab2 root]# /usr/lib/util-vserver/showattr /vservers
> >> /vservers       04000000
> >>
> >>
> >> i don't know what the appropriate option to setattr is to set
> the barrier
> >> bit, sorry.
> >>
> >>
> >>
> >> On Sun, 5 Jun 2005, Marc E. Fiuczynski wrote:
> >>
> >>> I have not looked into this type of problem before.  Is it fair
> >> to assume
> >>> that the cause of this problem is either a) the kernel not
> >> enforcing vserver
> >>> chroot properly, or b) the filesystem bits aren't setup
> >> properly from some
> >>> tool we use?
> >>>
> >>>> -----Original Message-----
> >>>> From: qa-bounces at planet-lab.org [mailto:qa-bounces at planet-lab.org]On
> >>>> Behalf Of Quality Assurance
> >>>> Sent: Sunday, June 05, 2005 8:21 AM
> >>>> To: qa at lists.planet-lab.org
> >>>> Subject: [QA] Failures for 2005.06.05
> >>>>
> >>>>
> >>>> 		=== qa Summary ===
> >>>>
> >>>> # of expected passes		139
> >>>> # of unexpected failures	4
> >>>> # of unexpected successes	2
> >>>>
> >>>> FAIL: vserver_chroot princeton_qa_0 at alice.cs.princeton.edu
> >>>> (Exploit seems to work. =))
> >>>> FAIL: vserver_chroot princeton_qa_1 at alice.cs.princeton.edu
> >>>> (Exploit seems to work. =))
> >>>> FAIL: vserver_chroot princeton_qa_0 at planetlab-2.cs.princeton.edu
> >>>> (Exploit seems to work. =))
> >>>> FAIL: vserver_chroot princeton_qa_1 at planetlab-2.cs.princeton.edu
> >>>> (Exploit seems to work. =))
> >>>>
> >>>> _______________________________________________
> >>>> QA mailing list
> >>>> QA at lists.planet-lab.org
> >>>> https://lists.planet-lab.org/mailman/listinfo/qa
> >>>
> >>> _______________________________________________
> >>> QA mailing list
> >>> QA at lists.planet-lab.org
> >>> https://lists.planet-lab.org/mailman/listinfo/qa
> >>>
> >
> > _______________________________________________
> > QA mailing list
> > QA at lists.planet-lab.org
> > https://lists.planet-lab.org/mailman/listinfo/qa
> >
>
> _______________________________________________
> QA mailing list
> QA at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/qa