pCloud appimage and Debian Buster

[Soviet_Mario]

I am a pCloud user coming from Debian Stretch.
Lately the pCloud team is releasing lots of updates, in the
form of a standalone (= local) appimage BINARY (a self
contained app).

Here on Stretch I've never met any problem in downloading
(either manually from the site or using internal downloader
of the desktop program), changing attributes enabling
EXECUTABLE flag, running and installing or updating.

But on the new machine (with Debian Buster) all the
aforementioned steps fail.

From the file manager double click on the (executably
enabled, folder writable) downloaded appimage package
produces no effect. The right click offers to open it with
non relevant applications, but there is no "RUN" command.
Using the terminal and launching, from user or root, prompt$
pCloud or prompt$ bash pCloud gives error messages.
I have sieved synaptic database for appimage-related stuff,
finding just two libraries, that moreover had just been
installed on Buster.

So what could be the problem ? pCloud team states : runs on
Debian 8 or LATER. Now on 9, 9.5 it runs smoothly, on 10
(which should be later) no ...

T.Y.

P.S. another aspect I don't understand is : the system seems
not to understand that the file is an executable. It does
not try executinga and then reports an error. Only forcing
execution from the shell produces errors.
when I try to type just "pcloud" at cmd prompt it says :
COMMAND NOT FOUND, if I prepend bash, it says IMPOSSIBLE TO
RUN THE BINARY FILE.





--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[J.O. Aho]

On 2020-05-30 15:02, Soviet_Mario wrote:

> P.S. another aspect I don't understand is : the system seems not to
> understand that the file is an executable. It does not try executinga
> and then reports an error.

Maybe the method you try to use in your UI file manager just ain't the
right way to do it?

try from console/terminal (assuming you are in the righ directory):
chmod 755 pcloud

> when I try to type just "pcloud" at cmd prompt it says : COMMAND NOT
> FOUND, if I prepend bash, it says IMPOSSIBLE TO RUN THE BINARY FILE.

the directory you are in ain't in the $PATH, try to add ./ infront, so
you get ./pcloud instead of just pcloud.

--

//Aho

[Soviet_Mario]

On 30/05/20 18:39, J.O. Aho wrote:
> On 2020-05-30 15:02, Soviet_Mario wrote:
>
>> P.S. another aspect I don't understand is : the system
>> seems not to understand that the file is an executable. It
>> does not try executinga and then reports an error.
>
> Maybe the method you try to use in your UI file manager just
> ain't the right way to do it?
>
> try from console/terminal (assuming you are in the righ
> directory): chmod 755 pcloud

the UI just reports executable flag correctly set.


please read till the end : I just stated I tried both with a
plain cmd from console (i called it Terminal, maybe a wrong
word, was that the reason for ignoring that ?) and by
prepending bash.

>
>> when I try to type just "pcloud" at cmd prompt it says :
>> COMMAND NOT FOUND, if I prepend bash, it says IMPOSSIBLE
>> TO RUN THE BINARY FILE.
>
> the directory you are in ain't in the $PATH, try to add ./

I tried to execute it directly from its folder (and when
using Terminal, I formerly used CD to go to that folder).
Beyond that, I believed appimages should be standalone with
no dependencies outside, so opening a terminal to the folder
where the file was should have been enough.

> infront, so you get ./pcloud instead of just pcloud.
>

Mmm .... I'm not sure I understand this point.
When I double click from Thunar onto a file, in which folder
I am ? I took for granted : the folder where the file was ....
in Terminal instead I explicidedly used CD to move to that
folder.

This time I guess there is sth wrong in the binary fmt
and/or some Buster setting put somewhere ...

[J.O. Aho]

On 2020-05-30 20:23, Soviet_Mario wrote:
> On 30/05/20 18:39, J.O. Aho wrote:

>> infront, so you get ./pcloud instead of just pcloud.
>>
>
> Mmm .... I'm not sure I understand this point.

The point is that if you use 'pcloud', then the directory needs to be in
you $PATH. This is easy to check, just "echo $PATH" and manually see if
the directory is listed or not. [I bet on that the directory ain't
listed in the output].

If you use './pcloud' you are telling the location of the file, so that
bash knows where to look for it as it's not included in the $PATH.


For example 'ls' is located in /bin directory, and /bin is part of the
$PATH, so you don't need to tell bash where the file is, it will look in
/bin and find ls and execute it.

> This time I guess there is sth wrong in the binary fmt and/or some
> Buster setting put somewhere ...

Yes, there is something wrong between the chair and the keyboard.

--

//Aho

[Soviet_Mario]

On 31/05/20 00:01, J.O. Aho wrote:
> On 2020-05-30 20:23, Soviet_Mario wrote:
>> On 30/05/20 18:39, J.O. Aho wrote:
>
>>> infront, so you get ./pcloud instead of just pcloud.
>>>
>>
>> Mmm .... I'm not sure I understand this point.
>
>
> The point is that if you use 'pcloud',

one moment, I am trying to install rather than to use the
program .... well, thinking twice about, maybe install is a
wrong word (as appimage should not install anything).
The package is being tried to be executed where it resides
(and what else should it look elsewhere in any case, having
no dependencies ?).
But it HAS to create other folders elsewhere (I did not
think of this before, somewhat your replies compelled me to
rethink the whole). It has to store configuration files,
some logins, and a CACHE (after running the program can move
it).
Do you think the binary finds error accessing those places ?
I dunno exactly where it wants to write files and neither do
I know if I could assume the same places it did under the
other PC/distro (I also moved the cache to a HDD drive away
of system SDD drive, and can't recall the default initial
location).

> then the directory
> needs to be in you $PATH. This is easy to check, just "echo
> $PATH" and manually see if the directory is listed or not.
> [I bet on that the directory ain't listed in the output].

not at all, but I opened manually a console in the same
folder the executable package is. I really cannot understand
the problem :\
I also readed that the FIRST place ever every program looks
for files (libraries and resources) is its CURRENT folder,
the same where the executable is (but for the case the
resources include a path, relative or absolute, in which
case some specialized scan will start I guess)

>
> If you use './pcloud' you are telling the location of the
> file, so that bash knows where to look for it as it's not
> included in the $PATH.

ok, tonight I'll try this cmd line

>
>
> For example 'ls' is located in /bin directory, and /bin is
> part of the $PATH, so you don't need to tell bash where the
> file is, it will look in /bin and find ls and execute it.
>
>
>> This time I guess there is sth wrong in the binary fmt
>> and/or some Buster setting put somewhere ...
>
> Yes, there is something wrong between the chair and the
> keyboard.

lol. A bit acidic but funny.
see later

[Soviet_Mario]

On 31/05/20 00:01, J.O. Aho wrote:

oh, back here

tried, both as root and as user ("admin")

root$ ./pcloud => permission denied
root$ bash ./pcloud => impossible to execute the binary file

user$ ./pcloud => permission denied
user$ bash ./pcloud => impossible to execute the binary file

(the file belongs to user and theoretically has read/write
access set, besides executable flag).

So I got a new kind of error reported (permission denied, to
downloaded folder) was never reported before.

I must admit I was skeptical, but did not know how to
explain the reason.
Now I am able : under Stretch no such dot slash notation was
ever required : i simply double clicked the installer and it
ran smoothly (yesterday at the latest, as pCloud released
another update).

Mboh .... I'll try to ask them, after all I am a paying
customer, not a free one.

ciao

[J.O. Aho]

On 01/06/2020 00:55, Soviet_Mario wrote:
> On 31/05/20 00:01, J.O. Aho wrote:
>> On 2020-05-30 20:23, Soviet_Mario wrote:
>>> On 30/05/20 18:39, J.O. Aho wrote:
>>
>>>> infront, so you get ./pcloud instead of just pcloud.
>>>>
>>>
>>> Mmm .... I'm not sure I understand this point.
>>
>>
>> The point is that if you use 'pcloud', then the directory needs to be
>> in you $PATH. This is easy to check, just "echo $PATH" and manually
>> see if the directory is listed or not. [I bet on that the directory
>> ain't listed in the output].
>>
>> If you use './pcloud' you are telling the location of the file, so
>> that bash knows where to look for it as it's not included in the $PATH.
>>
>>
>> For example 'ls' is located in /bin directory, and /bin is part of the
>> $PATH, so you don't need to tell bash where the file is, it will look
>> in /bin and find ls and execute it.
>>
>>
>>> This time I guess there is sth wrong in the binary fmt and/or some
>>> Buster setting put somewhere ...
>>
>> Yes, there is something wrong between the chair and the keyboard.
>>
>
> oh, back here
>
> tried, both as root and as user ("admin")
>
> root$ ./pcloud => permission denied
> root$ bash ./pcloud => impossible to execute the binary file

try "ls -l ./pcloud" and "lsattr ./pcloud" and copy paste the results of
those two results in your reply.

> So I got a new kind of error reported (permission denied, to downloaded
> folder) was never reported before.

This tend to be when you don't have permission to execute the file and
in most cases a simple "chmod 755 pcloud" would fix it.

> I must admit I was skeptical, but did not know how to explain the reason.
> Now I am able : under Stretch no such dot slash notation was ever
> required : i simply double clicked the installer and it ran smoothly
> (yesterday at the latest, as pCloud released another update).

the relative/full path has always been required for running programs
that do not residence within one of the directories in the $PATH, so
nothing new here.

appimage ain't an installer, so you never install it by double clicking
on the icon in the file manager, you execute it.

> Mboh .... I'll try to ask them, after all I am a paying customer, not a
> free one.

I would guess they tell you to set the execution bit, I suggest you use
the command line to do it and then use "ls -l" to verify that you have
set it.

--

//Aho

[Soviet_Mario]

ok, back here. The two outcomes are, respectively:

username$ -rwxrwxrwx 1 username sudo 56991978 may 30 03:01
./pcloud

username$ --------------e---- ./pcloud

I run the two commands from within the folder.
Should I have tried from /home instead ?

>
>
>> So I got a new kind of error reported (permission denied,
>> to downloaded folder) was never reported before.
>
> This tend to be when you don't have permission to execute
> the file and in most cases a simple "chmod 755 pcloud" would
> fix it.

I'm trying this too, back in a second

now, the output of the first command has changed in
username$ -rwxr-x-wx 1 username sudo 56991978 may 30 03:01
./pcloud


anyway, It gives the very same errors as before.

>
>
>> I must admit I was skeptical, but did not know how to
>> explain the reason.
>> Now I am able : under Stretch no such dot slash notation
>> was ever required : i simply double clicked the installer
>> and it ran smoothly (yesterday at the latest, as pCloud
>> released another update).
>
> the relative/full path has always been required for running
> programs that do not residence within one of the directories
> in the $PATH, so nothing new here.
>
> appimage ain't an installer, so you never install it by
> double clicking on the icon in the file manager, you execute
> it.
>
>
>> Mboh .... I'll try to ask them, after all I am a paying
>> customer, not a free one.
>
> I would guess they tell you to set the execution bit,

had premised to them this had just been done as the first
action upon dnld completion (as usual)

> I
> suggest you use the command line to do it and then use "ls
> -l" to verify that you have set it.

Actually I had just set before the lowest possible
privileges : everyone right to read, write, execute, and no
limit on the folder.
The binary maybe expects a different kernel or so ... dunno.
Buster uses kernels more recent than Stretch.
Boh. Now I wait for some response from their team.
Ah, the file is not corrupt. Dnlded at least 3 times, the
files are identical.



>

[J.O. Aho]

What about noexec option for your /home partition, run
"mount | grep home", if you see noexec, then your home directory is
mounted so that you can't execute any binaries/scripts in your home
directory.

Also apparmour/selinux/tomoyo may also be in play, those can be
configured to prevent file executions. Simplest would take a look at the
/var/log/audit.log (may be different in debian), but not sure you have
it, but you may need to use journaldctl to get some log information as I
guess you are running systemd.

--

//Aho

[Soviet_Mario]

very interesting .... Did you suspect this or desumed from
some encoded info in the output I reported ?

Anyway, the pCloud team has asked for more details about
versions and err messages (I gave it). They said it was not
tested on release 10.4 yet .... incidentally I made a
dist-upgrade and I am actually running such 10.4. But I'm
not very likely to think this might be that much different
from the previous versions.

> Also apparmour/selinux/tomoyo may also be in play, those can

Mmmmm .... I am afraid I have installed both apparmour and
selinux somewhat (but not configured anything manually). I
have to discover

> be configured to prevent file executions. Simplest would
> take a look at the /var/log/audit.log (may be different in
> debian), but not sure you have it, but you may need to use
> journaldctl to get some log information as I guess you are
> running systemd.

yes, I just asked systemd to tell details about versions to
answer the pcloud team.
Later I discovered I was forgetting a "/" before cat
etc/os-version and cat etc/debian_release. Damn slash !
I am simply terrified to read the systemD logs ....
I'm sure I would not understand anything.

But I'll try to see if at least in processes running there
appear apparmour and security enhanced linux ...

to finish with : in the FSTAB I have no dedicated partition
for home : I have it in the same as system root.

The pCloud file resides on a different disk (with data not
in home : i keep the most possible data out of home, both
for it's on a SSD, wherease MyData is on a huge HDD, and for
a worst case mistake).
Now I'll try to execute sth else from that disk/folder. If
sth goes wrong maybe THAT disk is mounted with no execution
flag (I did not even know such a flag existed at a whole
partition leve, I must admit ....)

Tnx for assistance !
Ciao

[Soviet_Mario]

On 30/05/20 15:02, Soviet_Mario wrote:

for those who might be intrested (and have read our 3D with
J O Aho

the pCloud team wrote me this request

<<Please enter the following command in the terminal and
share with us the output: fusermount -V >>

I got fusermount version 2.9.9


let's see what this mean ...

[J.O. Aho]

On 02/06/2020 15:13, Soviet_Mario wrote:
> On 01/06/20 22:17, J.O. Aho wrote:
>> On 01/06/2020 18:36, Soviet_Mario wrote:
>>> On 01/06/20 08:21, J.O. Aho wrote:

>> What about noexec option for your /home partition, run
>> "mount | grep home", if you see noexec, then your home directory is
>> mounted so that you can't execute any binaries/scripts in your home
>> directory.
>>
>
> very interesting .... Did you suspect this or desumed from some encoded
> info in the output I reported ?

I would say your issue is most likely related to that the file is not
executable even if it's marked as such on the file system, the next
logic one is that the file system mounted with the noexec option, which
prevents executions of files/scripts from that media.

> The pCloud file resides on a different disk (with data not in home

I suggest you will check the mounted device that you have stored the
binary on, this is simply done with the mount command without arguments,
you will see the current mount options.

> Mmmmm .... I am afraid I have installed both apparmour and selinux
> somewhat (but not configured anything manually). I have to discover

I would look into the audit log, as if it would somehow to be
apparmour/selinux interfering, you will see a decline message in the
audit log, but the error message tend to be another one than the one you
get.

>> be configured to prevent file executions. Simplest would take a look
>> at the /var/log/audit.log (may be different in debian), but not sure
>> you have it, but you may need to use journaldctl to get some log
>> information as I guess you are running systemd.
>
> yes, I just asked systemd to tell details about versions to answer the
> pcloud team.
> Later I discovered I was forgetting a "/" before cat etc/os-version and
> cat etc/debian_release. Damn slash !
> I am simply terrified to read the systemD logs ....

Now you made Lennart Poettering angry, the name is systemd and nothing else.

The logs from systemd don't differ much from a unified system logs, so
you need to filter things yourself. I think debian do enable to get the
logs split into readable files if you install a syslog of some kind.

> But I'll try to see if at least in processes running there appear
> apparmour and security enhanced linux ...

apparmour has a service and only active if the kernel is stated with the
apparmour enhancements.

SELinux on the other hand do not relay on a service, if it's enabled
it's enabled. Here you need to use the admin tools to see which state
it's running in.


--

//Aho

[Soviet_Mario]

On 04/06/20 07:34, J.O. Aho wrote:
> On 02/06/2020 15:13, Soviet_Mario wrote:
>> On 01/06/20 22:17, J.O. Aho wrote:
>>> On 01/06/2020 18:36, Soviet_Mario wrote:
>>>> On 01/06/20 08:21, J.O. Aho wrote:
>
>>> What about noexec option for your /home partition, run
>>> "mount | grep home", if you see noexec, then your home
>>> directory is mounted so that you can't execute any
>>> binaries/scripts in your home directory.
>>>
>>
>> very interesting .... Did you suspect this or desumed from
>> some encoded info in the output I reported ?
>
> I would say your issue is most likely related to that the
> file is not executable even if it's marked as such on the
> file system, the next logic one is that the file system
> mounted with the noexec option, which prevents executions of
> files/scripts from that media.
>

in FSTAB the disk is mounted with just defaults, 0 0 options

(while system disk has noatime, norelatime because it's SSD)

>
> > The pCloud file resides on a different disk (with data
> not in home
>
> I suggest you will check the mounted device that you have
> stored the binary on, this is simply done with the mount
> command without arguments, you will see the current mount
> options.
>
>
>> Mmmmm .... I am afraid I have installed both apparmour and
>> selinux somewhat (but not configured anything manually). I
>> have to discover
>
> I would look into the audit log, as if it would somehow to
> be apparmour/selinux interfering, you will see a decline
> message in the audit log, but the error message tend to be
> another one than the one you get.

I'll try catfish to look for such audit log

>
>>> be configured to prevent file executions. Simplest would
>>> take a look at the /var/log/audit.log (may be different
>>> in debian), but not sure you have it, but you may need to
>>> use journaldctl to get some log information as I guess
>>> you are running systemd.
>>
>> yes, I just asked systemd to tell details about versions
>> to answer the pcloud team.
>> Later I discovered I was forgetting a "/" before cat
>> etc/os-version and cat etc/debian_release. Damn slash !
>> I am simply terrified to read the systemD logs ....
>
> Now you made Lennart Poettering angry, the name is systemd
> and nothing else.

uh ?

>
> The logs from systemd don't differ much from a unified

oh I did not open the log, it gave the output on the stdout
(just the relavant part)

> system logs, so you need to filter things yourself. I think
> debian do enable to get the logs split into readable files
> if you install a syslog of some kind.

dunno.
To me logs it's like seeking a needle in an haystack, honestly

>
>
>> But I'll try to see if at least in processes running there
>> appear apparmour and security enhanced linux ...
>
> apparmour has a service and only active if the kernel is
> stated with the apparmour enhancements.

dunno : I did not explicitely configured anything, but if
during install, if package asks for sth I don't know the
best answer to, I simply tend to accept all defaults (under
MX I use "say yes to all", like Jim Carrey / God to the
prayers). It's not lazyness, it's I don't know actually what
to answer. If I install sth to just give it a try and study
it later, I cannot assume to know it in such an early stage).

>
> SELinux on the other hand do not relay on a service, if it's
> enabled it's enabled. Here you need to use the admin tools
> to see which state it's running in.

mmm ... work in progress

[Soviet_Mario]

On 30/05/20 15:02, Soviet_Mario wrote:

last update : case closed (almost)

Tnx to J.O.Aho first of all.

This is what I discovered.

pCloud team suggested to try previous versions to start with.
I went upstream 3 older versions. NONE worked any better
than latest.

Then I simply moved the installers on a /home subfolder.
Each one ran well (I aborted all but the latest, as I had
all of the installers available)

So this is what I replied to pCloud team

______________________________________________________

last updates :
each one of the installers refused to run.
Surprisingly enough, at least to me, all of them ran
smoothly from /home subfolder.

There might be some /home path hardwired somewhere.
Normally I do not download anything directly in the /home,
but I use to keep all of my stuff elsewere (on other
partitions and disks, with RW access though).
Pls check why your appimage runs only from subfolders of
/home ... it seems sort of a limitation.
But all well what ends well !
_____________________________________________________

I must admit I failed to correctly diagnose the actual problem.
If it is concerned with security (apparmor and SELinux) I
dunno, as well as I can't understand why this should make
any difference among /home subfolders and other partitions ....

but whichever was the problem, run from home disappeared. So
now I have pCloud working (I still have not rebooted the
system, I have a lot of other work halfway). I'll see if it
survives reboot too.

Mistery :\

[Soviet_Mario]

On 30/05/20 15:02, Soviet_Mario wrote:

I'd like to do further tests.
Do you know a very light and harmless APPIMAGE package to try ?

I want to clarify if the issue of being runned from /home or
its folders instead of another generic partition is a
general issue or limited to a few ones (or even to this
pCloud specifically) ...

pls give me an advice of a sw needing very little storage
elsewhere and leaving as little traces as possible

[J.O. Aho]

On 05/06/2020 23:57, Soviet_Mario wrote:
> On 30/05/20 15:02, Soviet_Mario wrote:
>
> I'd like to do further tests.
> Do you know a very light and harmless APPIMAGE package to try ?

Not much into appimages or other prepacked applications with libraries,
as I do see them as a security risk, as they do not get automatically
updated as the rest of the system, but you can look at

https://bintray.com/probono/AppImages/Atom#files

> I want to clarify if the issue of being runned from /home or its folders
> instead of another generic partition is a general issue or limited to a
> few ones (or even to this pCloud specifically) ...

You can test with a normal script, I doubt you can execute a script on
your mounted partition where you traditionally have your pcloud, try to
create a file, for example call it testscript and have the following
content:

#!/bin/bash
echo "I was executed as $0"

then do a "chmod 755 testscript"

and then run it ./testscript

> pls give me an advice of a sw needing very little storage elsewhere and
> leaving as little traces as possible

The script will take the least space, but on the other hand you should
remove the file after test, so then it don't matter if it takes a bit space.

I do recommend you use the mount command and look at the mount options
that the file system has, looking at the fstab is just telling you what
you wanted to be set, not what it was set in reality.


--

//Aho

[Soviet_Mario]

On 06/06/20 09:45, J.O. Aho wrote:
> On 05/06/2020 23:57, Soviet_Mario wrote:
>> On 30/05/20 15:02, Soviet_Mario wrote:
>>
>> I'd like to do further tests.
>> Do you know a very light and harmless APPIMAGE package to
>> try ?
>
> Not much into appimages or other prepacked applications with
> libraries, as I do see them as a security risk, as they do
> not get automatically updated as the rest of the system, but
> you can look at
>
> https://bintray.com/probono/AppImages/Atom#files

I'll read that

Actually pCloud "daemon" has its own internal updater. As it
is designed to be running in the background and connected to
network, he calls back home and "offers" to update when a
new version is available. This month 3 updates were put out.
I also noticed a positive change to the web interface
"client-view" (not owner view) in that it is starting to act
a bit like FTP explorer (maybe a feature a lot of users were
asking for when sharing whole folders not single files)

>
>
>> I want to clarify if the issue of being runned from /home
>> or its folders instead of another generic partition is a
>> general issue or limited to a few ones (or even to this
>> pCloud specifically) ...
>
> You can test with a normal script, I doubt you can execute a
> script on your mounted partition where you traditionally
> have your pcloud,

no my problem was with the DATA partition.
with "virtual" pCloud partition (who comes into existence
only once the daemon runs and mounts it as a phisical
partition, which is not) I prefer not to play with too
freely. I could corrupt sth. It is not a real disk-backed
(in fact It keeps a cache of REAL data onto another physical
disk still)


the problem was with the partition (physical and
pre-existing) where I wanted to launche the program from.
Once moved the "installer" to a home subfolder, the problem
simply disappeared.

I'll try to launch some script to just list files from there
.... but I don't think it as an ultimate proof.

I installed a huge bunch of other SW from there (95 % .DEB
packages, ran with GDEBI), maybe a .SNAP (freefylesync) and
maybe some .FLATPAKREF .... never had a single problem.
That's why I tend not to see this as a problem of the
partition "per se" and some global executable flag.

I am more likely to think as a problem of some hardwired
home-connected paths in the appimage.

My big partition DATA is not mounted as a subfolder of
home/username, but directly attached to ROOT /

and not by chance : I simply need to make that data equally
available to other users and/or distros (MX) on the same PC.
I prefer to give it an "extra-territorial" status


(I have symlinked in home too, but this does not likely matter)

> try to create a file, for example call it
> testscript and have the following content:
>
> #!/bin/bash
> echo "I was executed as $0"
>
> then do a "chmod 755 testscript"
>
> and then run it ./testscript
>

I'll try, but I'm rather sure it will execute as every other
SW (firefox, libreoffice, virtualbox, JRE, and a other .DEB
downloaded to have the most fresh available).

Maybe it's a bad habit, but with very big and famous SW i
tend to install from their website directly, not from the repo.

now that I remember, also JchemPaint and Alice3, and Scratch
were packaged shell scripts, and gave zero problems.


trying to understand why pCloud team could have wanted to
bind the appimage to /home/username .... maybe this has to
do with privacy of shared data. Granting only users (able to
run it) can run locally their "daemon" and mount and SEE the
virtual partition with owned data.
I dunno, just making hypotheses. But actually this is
starting to make sense from privacy point of view.


I have to understand if the autologin features (saved
credentials) are user-session bound or not ... I have a
single user so I cannot assess this (and I WONT CREATE
EXPERIMENTAL USERS to just understand this)

>
>> pls give me an advice of a sw needing very little storage
>> elsewhere and leaving as little traces as possible
>
> The script will take the least space, but on the other hand
> you should remove the file after test, so then it don't
> matter if it takes a bit space.
>
> I do recommend you use the mount command and look at the
> mount options that the file system has, looking at the fstab
> is just telling you what you wanted to be set, not what it
> was set in reality.
>

oh GOD ! Did not know this.
I'll try to do an ex-post diagnosis then.
tnx

[Soviet_Mario]

On 04/06/20 07:34, J.O. Aho wrote:

> On 02/06/2020 15:13, Soviet_Mario wrote:
>> On 01/06/20 22:17, J.O. Aho wrote:
>>> On 01/06/2020 18:36, Soviet_Mario wrote:
>>>> On 01/06/20 08:21, J.O. Aho wrote:
>

sorry, I reply here cause I cannot any more find your msg
where you stated FSTAB was somewhat no more than an "hint"
to mount some way, and to verify using MOUNT command (to my
surprise)

Today I tried the command you said, ad it turned out that
NOEXEC is reported for just that device.

The very unexplicable thing (to me) is that I have created
an entry for it just pasting the lines of another drive
(except for the UUIDs and mount directory obv, but I simply
copied the options :
defaults,rw,user

and the outcome is : all other devices are EX POST mounted
without NOEXEC flag, that one giving problems has it.

So you were right (I wrote a junk of bullshit trying to
figure out other reasons, lol), and I understand less and
less the reason why this happened and to solve (and why
other packages apparently circumvented the prohibition :
maybe or surely I have a wrong misconception of what really
is seen as an executable : .deb, .snap and "some" (?) .sh
are not seen so ... complete confusion).

Or even, some action (unclear to me, but I did edit FSTAB
manually) could have happened AFTER the stuff were installed
and BEFORE i tried to install pCloud.

So : whata can I do to make FSTAB being "obeyed" ?

or, less well, what can I do after login, to "remount" the
drive enabling with execution flag set properly ?

the attempts with mount command at terminal, have effect in
the current session only, right ?

One good thing is : no issue about apparmour and SELinux,
which I suspect would be much harder to fix

good diagnose remotely !

[J.O. Aho]

I would try to add the exec option in fstab, it seems like the
user/users option do add the noexec, from the mount man page:

user Allow an ordinary user to mount the filesystem. The name of the
mounting user is written to the mtab file (or to the private
libmount file in /run/mount on systems without a regular mtab)
so that this same user can unmount the filesystem again.
This option implies the options noexec, nosuid, and nodev
(unless overridden by subsequent options, as in the option line
user,exec,dev,suid).

> or, less well, what can I do after login, to "remount" the drive
> enabling with execution flag set properly ?
>
> the attempts with mount command at terminal, have effect in the current
> session only, right ?

you need to remount,

mount -o remount,exec /path/to/your/partition/mount/point

> One good thing is  : no issue about apparmour and SELinux, which I
> suspect would be much harder to fix

You would need to make some rules, selinux is more difficult to fix.


--

//Aho

[Soviet_Mario]

oh, I see. So case closed !
I'll try either to add exec or remove user (I added it for
no particular reason but trying to "relax" usage privileges
... only to discover today I had unwittingly made them more
restrictive. This has sth weird !)

I'll also look for mtab to see if I have this file and
what's in, if so

>
> user   Allow an ordinary user to mount the filesystem.  The
> name of the
>        mounting user is written to the mtab file (or to the
> private
>        libmount file in /run/mount on systems without a
> regular  mtab)
>        so that  this  same  user  can  unmount  the
> filesystem  again.
>        This  option  implies  the  options  noexec,
> nosuid,  and  nodev
>        (unless overridden by subsequent options, as in the
> option line
>        user,exec,dev,suid).
>
>> or, less well, what can I do after login, to "remount" the
>> drive enabling with execution flag set properly ?
>>
>> the attempts with mount command at terminal, have effect
>> in the current session only, right ?
>
> you need to remount,
>
> mount -o remount,exec /path/to/your/partition/mount/point
>
>
>> One good thing is  : no issue about apparmour and SELinux,
>> which I suspect would be much harder to fix
>
> You would need to make some rules, selinux is more difficult
> to fix.
>

shivers in the back

[J.O. Aho]

user/users do allow non-privileged users to mount/unmount the partition,
in that sense you did relax things, but as this would be a possible way
of introduce none certified binaries (from the system admin point of
view), it's been a security risk and also there been some issues with
auto exec (kind of the same as in microsoft windows) when mounting
devices in some desktop environments, so it's been deemed good to
prevent those file system to have exec enabled.

> I'll also look for mtab to see if I have this file and what's in, if so

It used to be a file, nowadays of you have /etc/mtab it's a symlink to
/proc/self/mounts and the content is the same as running mount without
any options.


--

//Aho

[Soviet_Mario]

On 06/06/20 09:45, J.O. Aho wrote:

to further confirm your diagnosis was correct : yesterday I
dnloaded another package (FreeFileSync) from their site, not
really an installer, an executable standalone "in place" :
again this refused to run from DATA partition, but run
smoothly when all the folders and executable was moved
ANYWHERE under /home.

[J.O. Aho]

Then add to your fstab exec to the specific partition mount instructions.

--

//Aho

[Soviet_Mario]

On 08/06/20 21:07, J.O. Aho wrote:
> On 08/06/2020 13.52, Soviet_Mario wrote:
>> On 06/06/20 09:45, J.O. Aho wrote:
>>> On 05/06/2020 23:57, Soviet_Mario wrote:
>>>> On 30/05/20 15:02, Soviet_Mario wrote:
>>>>

CUT

>> to further confirm your diagnosis was correct : yesterday
>> I dnloaded another package (FreeFileSync) from their site,
>> not really an installer, an executable standalone "in
>> place" : again this refused to run from DATA partition,
>> but run smoothly when all the folders and executable was
>> moved ANYWHERE under /home.
>
> Then add to your fstab exec to the specific partition mount
> instructions.

yes, I did it. On rescanning (using MOUNT command) after
reboot, another not explicitly required flag turned out :
NOSUID.
Does it imply some limitation ? Should I write, who wknows
... SUID ?

[David W. Hodgins]

On Mon, 08 Jun 2020 18:55:36 -0400, Soviet_Mario <Sovie...@cccp.mir> wrote:
> yes, I did it. On rescanning (using MOUNT command) after
> reboot, another not explicitly required flag turned out :
> NOSUID.
> Does it imply some limitation ? Should I write, who wknows
> ... SUID ?

Yes, though lower case suid. See man mount.

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

[J.O. Aho]

On 09/06/2020 00.55, Soviet_Mario wrote:
> On 08/06/20 21:07, J.O. Aho wrote:
>> On 08/06/2020 13.52, Soviet_Mario wrote:
>>> On 06/06/20 09:45, J.O. Aho wrote:
>>>> On 05/06/2020 23:57, Soviet_Mario wrote:
>>>>> On 30/05/20 15:02, Soviet_Mario wrote:
>>>>>
>
> CUT
>
>>> to further confirm your diagnosis was correct : yesterday I dnloaded
>>> another package (FreeFileSync) from their site, not really an
>>> installer, an executable standalone "in place" : again this refused
>>> to run from DATA partition, but run smoothly when all the folders and
>>> executable was moved ANYWHERE under /home.
>>
>> Then add to your fstab exec to the specific partition mount instructions.
>
> yes, I did it. On rescanning (using MOUNT command) after reboot, another
> not explicitly required flag turned out : NOSUID.
> Does it imply some limitation ? Should I write, who wknows ... SUID ?

nosuid will disable the user and group id, and as you already noticed
the opposite is suid.

There is also a nodev, this prevents similar files as those in /dev to
work on that file system, this can cause problems if you are having a
lxc container located on that file system. By default the lxc container
file system is located under /var/lib/lxc. Just a heads up, as I think
nodev is okay to have, otherwise the opposite is dev.

--

//Aho

[Soviet_Mario]

On 09/06/20 07:46, J.O. Aho wrote:
> On 09/06/2020 00.55, Soviet_Mario wrote:
>> On 08/06/20 21:07, J.O. Aho wrote:
>>> On 08/06/2020 13.52, Soviet_Mario wrote:
>>>> On 06/06/20 09:45, J.O. Aho wrote:
>>>>> On 05/06/2020 23:57, Soviet_Mario wrote:
>>>>>> On 30/05/20 15:02, Soviet_Mario wrote:
>>>>>>
>>
>> CUT
>>
>>>> to further confirm your diagnosis was correct :
>>>> yesterday I dnloaded another package (FreeFileSync) from
>>>> their site, not really an installer, an executable
>>>> standalone "in place" : again this refused to run from
>>>> DATA partition, but run smoothly when all the folders
>>>> and executable was moved ANYWHERE under /home.
>>>
>>> Then add to your fstab exec to the specific partition
>>> mount instructions.
>>
>> yes, I did it. On rescanning (using MOUNT command) after
>> reboot, another not explicitly required flag turned out :
>> NOSUID.
>> Does it imply some limitation ? Should I write, who wknows
>> ... SUID ?
>
> nosuid will disable the user and group id, and as you
> already noticed the opposite is suid.

which implies what ?

>
> There is also a nodev, this prevents similar files as those
> in /dev to work on that file system, this can cause problems
> if you are having a lxc container located on that file
> system.

how to discover this ? I mean, I'm not aware of any LXC
(never ever heard of this acronym), but might it be some
sort of default (or created unawarely) ?

> By default the lxc container file system is located
> under /var/lib/lxc.
> Just a heads up, as I think nodev is
> okay to have, otherwise the opposite is dev.

anyway there was no such "nodev" flag reported

[J.O. Aho]

On 09/06/2020 19.04, Soviet_Mario wrote:
> On 09/06/20 07:46, J.O. Aho wrote:
>> On 09/06/2020 00.55, Soviet_Mario wrote:
>>> On 08/06/20 21:07, J.O. Aho wrote:
>>>> On 08/06/2020 13.52, Soviet_Mario wrote:
>>>>> On 06/06/20 09:45, J.O. Aho wrote:
>>>>>> On 05/06/2020 23:57, Soviet_Mario wrote:
>>>>>>> On 30/05/20 15:02, Soviet_Mario wrote:
>>>>>>>
>>>
>>> CUT
>>>
>>>>> to further confirm your diagnosis was correct : yesterday I
>>>>> dnloaded another package (FreeFileSync) from their site, not really
>>>>> an installer, an executable standalone "in place" : again this
>>>>> refused to run from DATA partition, but run smoothly when all the
>>>>> folders and executable was moved ANYWHERE under /home.
>>>>
>>>> Then add to your fstab exec to the specific partition mount
>>>> instructions.
>>>
>>> yes, I did it. On rescanning (using MOUNT command) after reboot,
>>> another not explicitly required flag turned out : NOSUID.
>>> Does it imply some limitation ? Should I write, who wknows ... SUID ?
>>
>> nosuid will disable the user and group id, and as you already noticed
>> the opposite is suid.
>
> which implies what ?

That files will not be set as owned by the user/group that the file has
but by the one who mounted the disk.

>>
>> There is also a nodev, this prevents similar files as those in /dev to
>> work on that file system, this can cause problems if you are having a
>> lxc container located on that file system.
>
> how to discover this ? I mean, I'm not aware of any LXC (never ever
> heard of this acronym), but might it be some sort of default (or created
> unawarely) ?

If you don't know, then you don't use it.


--

//Aho

[Soviet_Mario]

I'm so unfamiliar with this ownership things ....
I mean, normally I put my single user of all machines in a
group of the same name, and in all machines and all distro I
manually assign (or simply check) the UID = 1000.

Do, that ownership record of files, track the whole username
or just its numerical ID ? If the latter, then the nosuid
would lose its relevance IN THE GIVEN contest (or am I wrong ?)

To me it is enough that, when I move removable media from a
PC to another, I would never risk to lose access on the
files on it, in that sense I'd prefer to chose the less
restrictive mount option (and ownership tracking)
But I'm realizing only now the mount command is so powerful
as to override the file-system level flags (or maybe I
misunderstood sth)

>
>>>
>>> There is also a nodev, this prevents similar files as
>>> those in /dev to work on that file system, this can cause
>>> problems if you are having a lxc container located on
>>> that file system.
>>
>> how to discover this ? I mean, I'm not aware of any LXC
>> (never ever heard of this acronym), but might it be some
>> sort of default (or created unawarely) ?
>
> If you don't know, then you don't use it.

jeah ! Feel safer :)

[J.O. Aho]

On 10/06/2020 23.50, Soviet_Mario wrote:
> On 09/06/20 20:16, J.O. Aho wrote:
>> On 09/06/2020 19.04, Soviet_Mario wrote:

>>>> nosuid will disable the user and group id, and as you already
>>>> noticed the opposite is suid.
>>>
>>> which implies what ?
>>
>> That files will not be set as owned by the user/group that the file
>> has but by the one who mounted the disk.
>
> I'm so unfamiliar with this ownership things ....
> I mean, normally I put my single user of all machines in a group of the
> same name, and in all machines and all distro I manually assign (or
> simply check) the UID = 1000.
>
> Do, that ownership record of files, track the whole username or just its
> numerical ID ? If the latter, then the nosuid would lose its relevance
> IN THE GIVEN contest (or am I wrong ?)

Owneship is based on the ID, it's just translated to the TEXT when using
ls and the opposite way when using chown.

Assume you have two users, your usual 1000 and 1001 (your evil twin
brother), if you have the nosuid and your brother mounts the disk, then
all files will be owned by 1001, which means you won't have access to
the files. On the other hand if you mount the disk, then he won't have
access to the file.

> To me it is enough that, when I move removable media from a PC to
> another, I would never risk to lose access on the files on it, in that
> sense I'd prefer to chose the less restrictive mount option (and
> ownership tracking)
> But I'm realizing only now the mount command is so powerful as to
> override the file-system level flags (or maybe I misunderstood sth)

When using the options user/users, it will automatically imply that you
also meant noexec, nodev, and nosuid, this is so by design. This is
documented in the man page for mount.

--

//Aho

[Carlos E.R.]

On 31/05/2020 21.12, Soviet_Mario wrote:
> On 31/05/20 00:01, J.O. Aho wrote:
>> On 2020-05-30 20:23, Soviet_Mario wrote:
>>> On 30/05/20 18:39, J.O. Aho wrote:
>>
>>>> infront, so you get ./pcloud instead of just pcloud.
>>>>
>>>
>>> Mmm .... I'm not sure I understand this point.
>>
>>
>> The point is that if you use 'pcloud',
>

> one moment, I am trying to install rather than to use the program ....
> well, thinking twice about, maybe install is a wrong word (as appimage
> should not install anything).
> The package is being tried to be executed where it resides (and what
> else should it look elsewhere in any case, having no dependencies ?).
> But it HAS to create other folders elsewhere (I did not think of this
> before, somewhat your replies compelled me to rethink the whole). It has
> to store configuration files, some logins, and a CACHE (after running
> the program can move it).
> Do you think the binary finds error accessing those places ?
> I dunno exactly where it wants to write files and neither do I know if I
> could assume the same places it did under the other PC/distro  (I also
> moved the cache to a HDD drive away of system SDD drive, and can't
> recall the default initial location).

No comment, as I don't know pcloud.

>
>> then the directory needs to be in you $PATH. This is easy to check,
>> just "echo $PATH" and manually see if the directory is listed or not.
>> [I bet on that the directory ain't listed in the output].
>

> not at all, but I opened manually a console in the same folder the
> executable package is. I really cannot understand the problem :\
> I also readed that the FIRST place ever every program looks for files
> (libraries and resources) is its CURRENT folder, the same where the
> executable is (but for the case the resources include a path, relative
> or absolute, in which case some specialized scan will start I guess)

A program may look first for things in the current folder, OR NOT. It
depends how it has been programmed to do.

Specifically, when you tell the shell (the shell is a program) to
execute 'pcloud', which is what you are doing by typing

pcloud

at the prompt, it will NOT look at the current folder. As you have been
told, the shell looks for pcloud ONLY in the directories listed in the
PATH environment variable, in order.

Remember, computers do what you tell them to do, not what you think you
tell them to do.

>> Yes, there is something wrong between the chair and the keyboard.
>

> lol. A bit acidic but funny.
> see later

happens to be true, almost always, no matter how experienced you are.

--
Cheers, Carlos.

[Carlos E.R.]

On 04/06/2020 13.25, Soviet_Mario wrote:
> On 04/06/20 07:34, J.O. Aho wrote:
>> On 02/06/2020 15:13, Soviet_Mario wrote:
>>> On 01/06/20 22:17, J.O. Aho wrote:
>>>> On 01/06/2020 18:36, Soviet_Mario wrote:
>>>>> On 01/06/20 08:21, J.O. Aho wrote:
>>
>>>> What about noexec option for your /home partition, run
>>>> "mount | grep home", if you see noexec, then your home directory is
>>>> mounted so that you can't execute any binaries/scripts in your home
>>>> directory.
>>>>
>>>
>>> very interesting .... Did you suspect this or desumed from some
>>> encoded info in the output I reported ?
>>
>> I would say your issue is most likely related to that the file is not
>> executable even if it's marked as such on the file system, the next
>> logic one is that the file system mounted with the noexec option,
>> which prevents executions of files/scripts from that media.

Ditto. It is obvious.

>>
>
> in FSTAB the disk is mounted with just defaults, 0 0 options

Forget fstab, just do as we asked you and run "mount".

>>> yes, I just asked systemd to tell details about versions to answer
>>> the pcloud team.
>>> Later I discovered I was forgetting a "/" before cat etc/os-version
>>> and cat etc/debian_release. Damn slash !
>>> I am simply terrified to read the systemD logs ....
>>
>> Now you made Lennart Poettering angry, the name is systemd and nothing
>> else.
>
> uh ?

It is not systemD, it is systemd.



--
Cheers, Carlos.

[Carlos E.R.]

On 06/06/2020 17.36, Soviet_Mario wrote:

> On 04/06/20 07:34, J.O. Aho wrote:
>> On 02/06/2020 15:13, Soviet_Mario wrote:
>>> On 01/06/20 22:17, J.O. Aho wrote:
>>>> On 01/06/2020 18:36, Soviet_Mario wrote:
>>>>> On 01/06/20 08:21, J.O. Aho wrote:
>>
>
> sorry, I reply here cause I cannot any more find your msg where you
> stated FSTAB was somewhat no more than an "hint" to mount some way, and
> to verify using MOUNT command  (to my surprise)
>
> Today I tried the command you said, ad it turned out that NOEXEC is
> reported for just that device.

ho ho ho! :-D

>
> The very unexplicable thing (to me) is that I have created an entry for
> it just pasting the lines of another drive (except for the UUIDs and
> mount directory obv, but I simply copied the options :
> defaults,rw,user
>
> and the outcome is : all other devices are EX POST mounted without
> NOEXEC flag, that one giving problems has it.

The "defaults" are not what you think they are :-p

And they can change depending on circumstances. Is it an external disk?
Then noexec is expected. Is it a FAT media? Then noexec.

>
> So you were right (I wrote a junk of bullshit trying to figure out other
> reasons, lol), and I understand less and less the reason why this
> happened and to solve (and why other packages apparently circumvented
> the prohibition : maybe or surely I have a wrong misconception of what
> really is seen as an executable : .deb, .snap and "some" (?) .sh are not
> seen so ... complete confusion).

An executable in Linux is simply a file that has that permission set. No
matter the extension or type. What will happen if try to run it... differs.

>
> Or even, some action (unclear to me, but I did edit FSTAB manually)
> could have happened AFTER the stuff were installed and BEFORE i tried to
> install pCloud.
>
> So : whata can I do to make FSTAB being "obeyed" ?

add "exec" to the options and mount again.

>
> or, less well, what can I do after login, to "remount" the drive
> enabling with execution flag set properly ?

umount, then mount it.

>
> the attempts with mount command at terminal, have effect in the current
> session only, right ?

Right.



--
Cheers, Carlos.