On Sat, Jun 6, 2020, at 2:25 PM, Charles Forsyth wrote:
> execute permission on files, meaning here non-directories, is a special
> variant of read. a file with mode 0111 can be opened with OEXEC and read(2)
> will work as well as exec(2),
> but can't be opened with OREAD, because it's not got an
On Sat, Jun 6, 2020, at 10:13 PM, o...@eigenstate.org wrote:
> > it's open() which is failing. i suppose it should.
> >
> > if the open fails, maybe access should stat the file, and if it's a
> > directory, try dirread(2). or maybe just opening it for reading will
> > work. i don't know, i'm new t
>> So, cd'ing into a directory withut +x leads
>> to an inescapabler trap.
> ...
> fossil just moved up another notch in my estimation because directory search
> restriction is so broken.
o...@eigenstate.org, what version of fossil were your experiments done on?
My observations are different:
te
>>> So, cd'ing into a directory withut +x leads
>>> to an inescapabler trap.
>> ...
>> fossil just moved up another notch in my estimation because directory search
>> restriction is so broken.
>
> o...@eigenstate.org, what version of fossil were your experiments done on?
> My observations are dif
>
> "search" is exactly the wrong word for what this bit does, because if you
> don't have "search" permission, the one thing you can still do is look at
> the names.
in ramfs, but that's a bug that no-one had noticed
On Mon, Jun 8, 2020 at 3:05 AM wrote:
> >>> So, cd'ing into a directory with
I see I'd misapplied the rule in walk(5) so fossil is fine. It has to do
with searching from . when you are there, which makes sense, not when
entering the directory from its parent,
so ignore that part of my earlier post.
On Mon, Jun 8, 2020 at 3:13 AM Charles Forsyth
wrote:
> "search" is exac
