On 2018-10-27, Al Viro wrote:
> On Sat, Oct 27, 2018 at 06:17:29PM +1100, Aleksa Sarai wrote:
>
> > I'm going to send out a v4 "soon" but I would like to know what folks
> > think about having resolveat(2) (or similar) to separate the scoping O_*
> > flags and produce an O_PATH -- since
On 2018-10-27, Al Viro wrote:
> On Sat, Oct 27, 2018 at 06:17:29PM +1100, Aleksa Sarai wrote:
>
> > I'm going to send out a v4 "soon" but I would like to know what folks
> > think about having resolveat(2) (or similar) to separate the scoping O_*
> > flags and produce an O_PATH -- since
> What is the proposed semantic of O_BENEATH with absolute paths -- I
> believe you don't have an openat(2) on FreeBSD (but please feel free to
> correct me)?
openat(2) is necessary for capability mode (since open(2) is not permitted),
but it turns out it was actually added to FreeBSD earlier
> What is the proposed semantic of O_BENEATH with absolute paths -- I
> believe you don't have an openat(2) on FreeBSD (but please feel free to
> correct me)?
openat(2) is necessary for capability mode (since open(2) is not permitted),
but it turns out it was actually added to FreeBSD earlier
On Sat, Oct 27, 2018 at 06:17:29PM +1100, Aleksa Sarai wrote:
> I'm going to send out a v4 "soon" but I would like to know what folks
> think about having resolveat(2) (or similar) to separate the scoping O_*
> flags and produce an O_PATH -- since unsupported O_* flags are ignored
> by older
On Sat, Oct 27, 2018 at 06:17:29PM +1100, Aleksa Sarai wrote:
> I'm going to send out a v4 "soon" but I would like to know what folks
> think about having resolveat(2) (or similar) to separate the scoping O_*
> flags and produce an O_PATH -- since unsupported O_* flags are ignored
> by older
On 2018-10-27, Ed Maste wrote:
> On Tue, 9 Oct 2018 at 02:53, Aleksa Sarai wrote:
> >
> > +#ifndef O_BENEATH
> > +#define O_BENEATH 0004000 /* *Not* the same as capsicum's
> > O_BENEATH! */
> > +#endif
> [...]
> O_BENEATH originally came from the Capsicum Linux port, and inherited the
On 2018-10-27, Ed Maste wrote:
> On Tue, 9 Oct 2018 at 02:53, Aleksa Sarai wrote:
> >
> > +#ifndef O_BENEATH
> > +#define O_BENEATH 0004000 /* *Not* the same as capsicum's
> > O_BENEATH! */
> > +#endif
> [...]
> O_BENEATH originally came from the Capsicum Linux port, and inherited the
On Tue, 9 Oct 2018 at 02:53, Aleksa Sarai wrote:
>
> +#ifndef O_BENEATH
> +#define O_BENEATH 0004000 /* *Not* the same as capsicum's
> O_BENEATH! */
> +#endif
I had originally followed up privately to Aleksa about this comment (to
suggest that it's outdated and should be removed), but
On Tue, 9 Oct 2018 at 02:53, Aleksa Sarai wrote:
>
> +#ifndef O_BENEATH
> +#define O_BENEATH 0004000 /* *Not* the same as capsicum's
> O_BENEATH! */
> +#endif
I had originally followed up privately to Aleksa about this comment (to
suggest that it's outdated and should be removed), but
On Wed, Oct 10, 2018 at 12:08 AM Aleksa Sarai wrote:
>
> On 2018-10-09, Andy Lutomirski wrote:
> > On Mon, Oct 8, 2018 at 11:53 PM Aleksa Sarai wrote:
> > > * AT_NO_PROCLINK: Disallows ->get_link "symlink" jumping. This is a very
> > > specific restriction, and it exists because
On Wed, Oct 10, 2018 at 12:08 AM Aleksa Sarai wrote:
>
> On 2018-10-09, Andy Lutomirski wrote:
> > On Mon, Oct 8, 2018 at 11:53 PM Aleksa Sarai wrote:
> > > * AT_NO_PROCLINK: Disallows ->get_link "symlink" jumping. This is a very
> > > specific restriction, and it exists because
On 2018-10-10, Aleksa Sarai wrote:
> On 2018-10-09, Andy Lutomirski wrote:
> > On Mon, Oct 8, 2018 at 11:53 PM Aleksa Sarai wrote:
> > > * AT_NO_PROCLINK: Disallows ->get_link "symlink" jumping. This is a very
> > > specific restriction, and it exists because /proc/$pid/fd/...
> > >
On 2018-10-10, Aleksa Sarai wrote:
> On 2018-10-09, Andy Lutomirski wrote:
> > On Mon, Oct 8, 2018 at 11:53 PM Aleksa Sarai wrote:
> > > * AT_NO_PROCLINK: Disallows ->get_link "symlink" jumping. This is a very
> > > specific restriction, and it exists because /proc/$pid/fd/...
> > >
On 2018-10-09, Andy Lutomirski wrote:
> On Mon, Oct 8, 2018 at 11:53 PM Aleksa Sarai wrote:
> > * AT_NO_PROCLINK: Disallows ->get_link "symlink" jumping. This is a very
> > specific restriction, and it exists because /proc/$pid/fd/...
> > "symlinks" allow for access outside nd->root and pose
On 2018-10-09, Andy Lutomirski wrote:
> On Mon, Oct 8, 2018 at 11:53 PM Aleksa Sarai wrote:
> > * AT_NO_PROCLINK: Disallows ->get_link "symlink" jumping. This is a very
> > specific restriction, and it exists because /proc/$pid/fd/...
> > "symlinks" allow for access outside nd->root and pose
On Mon, Oct 8, 2018 at 11:53 PM Aleksa Sarai wrote:
> * AT_NO_PROCLINK: Disallows ->get_link "symlink" jumping. This is a very
> specific restriction, and it exists because /proc/$pid/fd/...
> "symlinks" allow for access outside nd->root and pose risk to
> container runtimes that don't want
On Mon, Oct 8, 2018 at 11:53 PM Aleksa Sarai wrote:
> * AT_NO_PROCLINK: Disallows ->get_link "symlink" jumping. This is a very
> specific restriction, and it exists because /proc/$pid/fd/...
> "symlinks" allow for access outside nd->root and pose risk to
> container runtimes that don't want
Add the following flags to allow various restrictions on path
resolution (these affect the *entire* resolution, rather than just the
final path component -- as is the case with most other AT_* flags).
The primary justification for these flags is to allow for programs to be
far more strict about
Add the following flags to allow various restrictions on path
resolution (these affect the *entire* resolution, rather than just the
final path component -- as is the case with most other AT_* flags).
The primary justification for these flags is to allow for programs to be
far more strict about
20 matches
Mail list logo
