Creating a folder with the same name as the file in the autostart folder is a workaround.

But the issue is that the autostart KCM just reads the state from these autostart files. If the program decides to override these files then there is nothing preventing it from doing so.

> Creating a folder with the same name as the file in the autostart folder is a workaround.

guess also permission should be changed to avoid the program to delete the folder, also this assume the program will not simply try to create a file with a different name..

Please click on Team's systray icon and you will see "Get logs", "Settings >", "Open" and "Quit". In "Settings >" you will be able to find the option "Do not auto-start Teams".

Created attachment 130066 [details]
attachment-26320-0.html

Thanks, but please note this is just an example on how the system is not
properly working:
the "Status" checkbox and the abusability of the system itself.


On Sun, 12 Jul 2020, 13:47 , <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=424118
>
> --- Comment #3 from 2wxsy58236r3@opayq.com ---
> Please click on Team's systray icon and you will see "Get logs", "Settings
> >",
> "Open" and "Quit". In "Settings >" you will be able to find the option "Do
> not
> auto-start Teams".
>
> --
> You are receiving this mail because:
> You reported the bug.

I think this may not be a KDE bug but an issue with the XDG Autostart Specification, and you can go to their mailing list [1] for discussion.

[1] https://lists.freedesktop.org/mailman/listinfo/xdg

Indeed. While this is clearly an issue with Microsoft Teams behaving badly (booo), it's also Plasma's job to provide a sane and sensible environment for apps to run in, which sometimes includes protecting the user from badly-behaving apps. Perhaps we could have Plasma notice when an application tries to make itself autostarted, and then ask the user if this is really desired.

@Nate Graham was looking into it and intercepting "file open" to hang them until filtered require quite a bit of magic in the kernel (https://unix.stackexchange.com/questions/394323/intercepting-file-access-events)

or there is the quick and dirty way to use inotify, on new file change them to disable (hidden proprierty to true?), change ownership to something else non application writable (probably a custom user here), and finally visualize the request windows to the user asking for confirmation.  
  
the order of operation is made in a way that even if the application that check crash/fail (inotify may fail, or pc may get shut down in that very moment) at the next start the .desktop that has no correct ownership will not started, and the later when the script start it will process them.  
  
I think i can quickly write the script if the idea is accepted.

Idea:
1. Plasma keeps an internal list of autostart apps, and this list will be updated when the user changes the configuration via KDE System Settings.
2. During the session, the user or a badly-behaving app may have manually changed the autostart configuration.
3. When ending a Plasma session (e.g. logout/shutdown/restart), compare the contents of autostart directory to the internal autostart list. If difference is found, e.g. a new app to be autostarted, inform the user.

>Perhaps we could have Plasma notice when an application tries to make itself autostarted, and then ask the user if this is really desired.

This is out of scope and any implementation at a plasma level would be a horrible hack. It's our duty to list things in the XDG autostart dirs but nothing more.

Hopefully we will move to see more sandboxing of applications.

I took a look at the XDG specification here: https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html

and there is no reference about user should or should not be asked for BUT after mount:

> Autostart Of Applications After Mount
> [...]
> The desktop environment MUST prompt the user for confirmation before automatically starting an application. 

so IMHO implementing a confirmation system is not against the XDG standard and not an horrible hack (that depends on implementation), as is quite clear the user can always disable the autostart by setting the Hidden flag;
and automation of the process of discovery of new entry is just a nice feature (and actually potential security fix).

I see how discussing with them for a correct/standardized solution can benefit

> we will move to see more sandboxing of applications.

I fail to see how this would help, if a sandboxed application want to autostart (and follow current XDG standard):
- it always cant (bad user experience)
- it always can (as of now)
- ask the user (as proposed here)

---------

also found the fanotify API: https://man7.org/linux/man-pages/man7/fanotify.7.html

that can clean up the system proposed quite a bit, as it can intercept read/write/delete (not creation, but empty file should not be a problem), the advantage is the file permission and content does NOT need to change, so deletion of the file from the application will still work.

@2wxsy58236r3: yes, a list of existing entry should be keep, and ideally also a list of "remember my decision" to avoid app that try to set those file in a loop to spam-bomb the user.  
If you used PrivacyGuard in Android to granular control permission, you probably know the issue

>I fail to see how this would help, if a sandboxed application want to autostart (and follow current XDG standard):
- it always cant (bad user experience)
- it always can (as of now)
- ask the user (as proposed here)


It is as follows:
 - app can't write in our autostart directory
 - they call a portal implementation to request autostart
 - we show a prompt and install the file

This is upstream in the portals as https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Background.xml
(though with some extra stuff about detecting backgrounded apps)

and we have a KDE implementation already within xdg-desktop-portal-kde/background.cpp 

BackgroundPortal::EnableAutostart doesn't look like we prompt currently. I would 100% support adding any UI code there.

Killer difference with this is that we're not trying to do it retroactively react but we position the workspace into a controlled flow.

oh i see, the real deal here is there is a complete different protocol, instead of creating a file the application make an actual request.  
Not sure how this is going to impact legacy app, guess the container can see XDG folder and generate the request to the system instead.

> Killer difference with this is that we're not trying to do it retroactively react but we position the workspace into a controlled flow.

i think i can get something similar with fanotify. Ill experiment a bit and make a proof of concept

So it end up being way easier than expected, ended up finding an almost perfect example in stackoverflow and the man page (https://man7.org/linux/man-pages/man7/fanotify.7.html)
I played a with with https://gist.github.com/lestofante/caf518e6ae560cb0dc92beb264731141

I didnt find any API to make simple KDialog from C so I did just put a quick and dirty user terminal read.

The request for permission happen BEFORE the file gets created/modified/deleted

Issues so far:
- you can bypass it with low level call, for example remote network mount will not work
- if the program crash the folder became writable
- you can't make the folder without write permission/other owner and then bypass it with this system

FAN_CLASS_PRE_CONTENT

will require root no?

yes, the exact permission i think is CAP_SYS_ADMIN and looks required always, not only for FAN_CLASS_PRE_CONTENT.  

So it has to run as daemon with tailored permission, and probably the configuration/gui part split into an unprivileged process.  
  
on the other end would became possible to be used for other stuff too (like systemd user service) and even user own preference, and can spin off as a standalone application, and later we may discuss if it make sense to be included by default and what folder it should check.

In this world of cryptovirus, make sense that a user may want to protect some of its folder so only some specific application can access them.

Basically this would be an file system application firewall