Others may know this already, but I thought it was worth passing on.

When a directory has "x" in its permissions, that allows a command to
search in the directory. Selecting an executable file in that directory
by name, seems to be still possible. I had that happen yesterday.
Everything in the program worked, except that it couldn't find the configuration file. It was the only essential file the program couldn't
find The permissions on the directory were 666, and the command came
from outside it. Changing the permissions on the folder to 776 solved
the problem.

--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 25/8/21 4:10 am, Doug Laidlaw wrote:

Others may know this already, but I thought it was worth passing on.

When a directory has "x" in its permissions, that allows a command to
search in the directory.  Selecting an executable file in that directory
by name, seems to be still possible.  I had that happen yesterday. Everything in the program worked, except that it couldn't find the configuration file.  It was the only essential file the program couldn't find  The permissions on the directory were 666, and the command came
from outside it.  Changing the permissions on the folder to 776 solved
the problem.

exactly! I remember when I delved into the file permission stuff there
was a folder setting that rendered the folder unreadable and content
could not be listed, BUT if the name of a file was known then it could
still be accessed.

File permission is not for the faint of heart - I've always scuttled away.


--
faeychild
Running plasmashell 5.20.4 on 5.10.41-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 25.08.2021 at 07:51, faeychild scribbled:

On 25/8/21 4:10 am, Doug Laidlaw wrote:

Others may know this already, but I thought it was worth passing on.
=20
When a directory has "x" in its permissions, that allows a command
to search in the directory.=C2=A0 Selecting an executable file in that directory by name, seems to be still possible.=C2=A0 I had that happen yesterday. Everything in the program worked, except that it
couldn't find the configuration file.=C2=A0 It was the only essential
file the program couldn't find=C2=A0 The permissions on the directory
were 666, and the command came from outside it.=C2=A0 Changing the permissions on the folder to 776 solved the problem. =20

=20
exactly! I remember when I delved into the file permission stuff
there was a folder setting that rendered the folder unreadable and
content could not be listed, BUT if the name of a file was known then
it could still be accessed.

If the directory has +x permission for your account but not +r, then
you can still access files therein if you know their name. If it has
+r for you but not +x, then you can list its contents, but you won't be
able to access its files.
=20

File permission is not for the faint of heart - I've always scuttled
away.

=20
I've written a long but elaborate tutorial on POSIX permissions and file ownership over at the Manjaro forum. The tutorial is publicly
accessible.

<https://forum.manjaro.org/t/tutorial-understanding-and-working-with-unix= -filesystems-and-permissions/65793>


--=20
With respect,
=3D Aragorn =3D


--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: A noiseless patient Strider (2:250/1@fidonet)

On 25/8/21 9:33 am, Aragorn wrote:

I've written a long but elaborate tutorial on POSIX permissions and file ownership over at the Manjaro forum. The tutorial is publicly
accessible.

<https://forum.manjaro.org/t/tutorial-understanding-and-working-with-unix-filesystems-and-permissions/65793>

It's Bookmarked. It's epic

I cant promise to read it but it may happen :-)


--
faeychild
Running plasmashell 5.20.4 on 5.10.41-desktop-1.mga8 kernel.
Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On 2021-08-24, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:

Others may know this already, but I thought it was worth passing on.

When a directory has "x" in its permissions, that allows a command to
search in the directory. Selecting an executable file in that directory

No, it allows a command to run or open a specifically named file. It
does not allow you to search or read the filenames in that directory.
Thus ls dir does not work, but if there is a file called abbie, you can
open dir/abbie but only if you know the exact name of the file. Thus
ls dir/abbi? does not work, but ls dir/abbie should.

d-wx--x--x 2 root root 60 Aug 26 19:04 .
drwxrwxrwt 16 root root 380 Aug 26 19:03 ..
-rw-r----- 1 root root 0 Aug 26 19:04 abbie
#l dir/
/bin/ls: cannot open directory 'dir/': Permission denied
#ls dir/abbie
dir/abbie
#ls dir/abbi?
/bin/ls: cannot access 'dir/abbi?': No such file or directory

by name, seems to be still possible. I had that happen yesterday. Everything in the program worked, except that it couldn't find the configuration file. It was the only essential file the program couldn't find The permissions on the directory were 666, and the command came
from outside it. Changing the permissions on the folder to 776 solved
the problem.

--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Fri, 27 Aug 2021 02:11:04 +0000, William Unruh wrote:

On 2021-08-24, Doug Laidlaw <laidlaws@hotkey.net.au> wrote:

Others may know this already, but I thought it was worth passing on.

When a directory has "x" in its permissions, that allows a command to
search in the directory. Selecting an executable file in that
directory

No, it allows a command to run or open a specifically named file. It
does not allow you to search or read the filenames in that directory.
Thus ls dir does not work, but if there is a file called abbie, you can
open dir/abbie but only if you know the exact name of the file. Thus ls dir/abbi? does not work, but ls dir/abbie should.

Do I detect confusion due to failure to distinguish who the permissions
apply to? Neither user (owner, group, other) nor the file or directory determine who can read or do what but the combination of them is required.

d-wx--x--x 2 root root 60 Aug 26 19:04 .

The directory . above is writable only by its owner, but may be
searched by owner, group, or other. A file with permission x is
executable by owner, group, or everyone, depending on who the
x permission pertains to.

drwxrwxrwt 16 root root 380 Aug 26 19:03 ..

The directory .. one level up is readable, writable, and searchable by
owner, group, and other, i.e. anyone.

-rw-r----- 1 root root 0 Aug 26 19:04 abbie #l dir/

File abbie is readable by owner (root) and group (anyone in root group), writable by owner root, but not by group or other. One not root or in
group root cannot read, write, or execute abbie.

/bin/ls: cannot open directory 'dir/': Permission denied #ls dir/abbie

Where did "'dir'" come from? Do you have current working directory
aliased to dir ??? I.e. . == `pwd`

If so, . == dir is not readable by anyone, per d-wx--x--x above.

dir/abbie #ls dir/abbi?

Typo on abbi ??

/bin/ls: cannot access 'dir/abbi?': No such file or directory

by name, seems to be still possible. I had that happen yesterday.
Everything in the program worked, except that it couldn't find the
configuration file. It was the only essential file the program
couldn't find The permissions on the directory were 666, and the
command came from outside it. Changing the permissions on the folder
to 776 solved the problem.

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely
expects users to be computer friendly.

--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/1@fidonet)

On Wed, 25 Aug 2021 01:33:33 +0200, Aragorn wrote:

I've written a long but elaborate tutorial on POSIX permissions and file ownership over at the Manjaro forum. The tutorial is publicly
accessible.

<https://forum.manjaro.org/t/tutorial-understanding-and-working-with-

unix-filesystems-and-permissions/65793>

hmmm I guess Copy and Paste is the only way to save this file in the
Computer for printing..

--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 29.08.2021 at 04:35, santo scribbled:

On Wed, 25 Aug 2021 01:33:33 +0200, Aragorn wrote:

I've written a long but elaborate tutorial on POSIX permissions and
file ownership over at the Manjaro forum. The tutorial is publicly accessible.

<https://forum.manjaro.org/t/tutorial-understanding-and-working-with-
unix-filesystems-and-permissions/65793>

hmmm I guess Copy and Paste is the only way to save this file in the Computer for printing..

I do have the file on my computer as a plain text file -- the Manjaro
forum has crashed before, and I wanted to make sure that I've got a
backup of my tutorials in case it happens again -- but it still contains
all of the BBcode formatting tags.

If there were an easy way to seamlessly convert BBcode into HTML or into
some other markup language, then I'm not aware of it. But I am open
to suggestions. ;)

--
With respect,
= Aragorn =


--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: A noiseless patient Strider (2:250/1@fidonet)

On 28/8/21 12:02 am, Jim wrote:

On 2021-08-24, Doug Laidlaw<laidlaws@hotkey.net.au> wrote:

Others may know this already, but I thought it was worth passing on.

When a directory has "x" in its permissions, that allows a command to
search in the directory. Selecting an executable file in that
directory

No, it allows a command to run or open a specifically named file. It
does not allow you to search or read the filenames in that directory.

What I was trying to do is what is stated in the last two sentences.
I have seen "search in the directory" used. Maybe the word "search" was
meant differently. Whatever the problem was in my case, I seem to have followed the wrong trail. Even making the director searchable by owner
and group was only a temporary fix, and didn't survive overnight. After trying all the hints on the Firestorm Help page and everything else I
could think of, I adopted my usual "repair" in these cases: I ran an
upgrade reinstall (using the "Upgrade Mageia 8" on the installer's
menu.) That procedure does nothing that is apparent, but it seems often
to fix quirks like this one. It hasn't repaired a similar one, however.
Windows is no longer added to the Grub menu, although the folder is
visible and searchable from Linux. A stanza I put in 40_custom does
still work, however, so I boot from that.

--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)

On 30/8/21 10:15 pm, Doug Laidlaw wrote:

On 28/8/21 12:02 am, Jim wrote:

On 2021-08-24, Doug Laidlaw<laidlaws@hotkey.net.au>  wrote:

Others may know this already, but I thought it was worth passing on.

When a directory has "x" in its permissions, that allows a command to
search in the directory.  Selecting an executable file in that
directory

No, it allows a command to run or open a specifically named file. It
does not allow you to search or read the filenames in that directory.

What I was trying to do is what is stated in the last two sentences.
I have seen "search in the directory" used.  Maybe the word "search" was meant differently.  Whatever the problem was in my case, I seem to have followed the wrong trail.  Even making the director searchable by owner
and group was only a temporary fix, and didn't survive overnight.  After trying all the hints on the Firestorm Help page and everything else I
could think of, I adopted my usual "repair" in these cases: I ran an
upgrade reinstall (using the "Upgrade Mageia 8" on the installer's
menu.)  That procedure does nothing that is apparent, but it seems often
to fix quirks like this one.  It hasn't repaired a similar one, however.
 Windows is no longer added to the Grub menu, although the folder is visible and searchable from Linux.  A stanza I put in 40_custom does
still work, however, so I boot from that.

My computer "spat the dummy" yesterday. Nothing would load. It turned
out to be corrupted BIOS settings. I removed the 3 volt battery for a
while (it had been in service for only a few weeks,) and it all came
good, without any loss of data. Hopefully, it will clean up some of the
recent bugs.

--- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
* Origin: Aioe.org NNTP Server (2:250/1@fidonet)