wineboot: Start items in StartUp folder on boot.

richardvoigt at gmail.com richardvoigt at gmail.com
Sat Feb 10 23:55:08 CST 2007


On 2/10/07, Jacob Alberty <jacob.alberty at vetmanage.com> wrote:
> Why not integrate this functionality into wineboot? That way if a user wants
> to completely deny the start-up folder they can just not add wineboot to the
> list of programs to be started on login, but if they want that functionality
> they can simply add wineboot to the list of programs for start up when they
> login? It would allow similar functionality to windows whilst still keeping
> it a separate system.

I think everyone agrees that wineboot is where this functionality
should be, if it's implemented at all?

Well, part of my idea was that even if the configuration option is set
to "silently deny", any option that was previously accepted with the
don't ask again option checked (or Always in case wine has buttons for
Never, Not This Time, Run This Time, Always) would still execute,
which is rather different from totally disabling wineboot.  Then you
could presumably run wineboot explicitly or some helper program, in
order to manage the entries.

>
>
> On 2/10/07, richardvoigt at gmail.com <richardvoigt at gmail.com> wrote:
> > On 2/10/07, David Lichterman <laviddichterman at gmail.com > wrote:
> > > Stefan Dösinger wrote:
> > > > Am Samstag 10 Februar 2007 05:20 schrieb Vitaliy Margolen:
> > > >> Misha Koshelev wrote:
> > > >>> Hi,
> > > >>>
> > > >>> As you all may have noticed, I have been making quite a few patches
> > > >>> within the last two weeks (or at least quite a few when compared to
> zero
> > > >>> before then) because I had figured out that the Vector NTI program
> that
> > > >>> is quite important in molecular biologThis patch makes sure that
> wine
> > > >>> will start items in the StartUp folder
> > > >> IMHO this should not be fixed.
> > > >>
> > > >> I've seen lots and lots of malicious programs using this mechanism to
> > > >> start themselves. And even worse if installer uses this to restart
> > > >> itself. That means this installer might not work most of the time on
> > > >> windows.
> > > > Malicious programs can also write themselves to
> > > > HKLM/Software/Microsoft/Windows/Run, a key that
> wineboot reads. So I do not
> > > > see any advantage in implementing the Run key, but not the autostart
> folder.
> > > >
> > > >
> > > >
> ------------------------------------------------------------------------
> > > >
> > > >
> > > I second that opinion. I do computer tech support (ie getting viruses
> > > and spy/malware off of windows) at my university and if there's a case
> > > for not implementing one of those two run at boot features, disabling
> > > the Run key would be the stronger since most, if not all malicious
> > > programs now use the run registry location as opposed to the Startup
> folder.
> > >
> > > It really comes down to the amount of power a user should have. Maybe
> > > require a gksu whenever an app tries to write something to that folder
> > > or that registry location?
> >
> > What a gksu?
> >
> > How about prompting the user during startup?
> >
> > e.g., "Start <title> using command line <program + args>?  Yes/No ([x]
> > Don't ask again"
> > Don't ask again items could either be stored as hash codes in a
> > configuration file outside the wine filesystem, or else by deleting
> > command/moving to a usual Unixy autostart location.
> >
> > This should be done for all startup programs, whether start menu or
> registry.
> >
> > It would be the best of both worlds, it works as expected for the user
> > without requiring them to give up control of their system.
> >
> > There could even be a winecfg option whether to prompt the user,
> > silently allow, automatically+loudly deny, or silently deny.
> >
> >
> >
>
>



More information about the wine-devel mailing list