[SailfishDevel] Scriptlets in RPM hot allowed to Harbour
Marcin M.
marmistrzmar at gmail.com
Sat Jan 11 16:53:15 UTC 2014
Hi,
Sorry, I forgot about PackageKit! ;) I was still in the apt world :)
Regards,
--
Marcin
2014/1/11 Mike Sheldon <mike at mikeasoft.com>
> Hi Marcin,
>
> On Sat, 2014-01-11 at 16:49 +0100, Marcin M. wrote:
> > So how else can we update sudoers...? No custom package manager could
> > be done without it.
>
> As I understand it you don't need to be root to carry out package
> management tasks on Sailfish due to the way it implements packagekit,
> which you can communicate with via dbus. Take a look at pkcon as an
> example of a command line packagekit client, you'll notice that running
> "pkcon install foo" or "pkcon remove bar" all works as the normal nemo
> user. In addition to this "ssu" can be used to add new repositories.
>
> You might also want to checkout the new warehouse client for an example
> of a custom graphical package manager:
> http://talk.maemo.org/showpost.php?p=1404764&postcount=194
>
> Cheers,
> Mike.
>
> > 2014/1/11 Thomas Perl <th.perl at gmail.com>
> > Duty calls[1]...
> >
> > tl;dr: No postinst scripts in Harbour. chmod 666 stuff
> > in /usr/ is wrong.
> >
> > On 11 Jan 2014, at 13:51, Martin Kolman
> > <martin.kolman at gmail.com> wrote:
> > > 11.1.2014 13:34, Alejandro Exojo:
> > >>> QA can check if post script doing some good job and allow
> > it?
> > >> If the script is simple, yes. If it is not, there is a
> > serious risk that
> > >> somebody adds a trojan horse to the phone.
> > >>
> > >> That would mean that somebody has to define what is a
> > simple script. And that a
> > >> problem in QA could mean a trojan horse is added to users'
> > phones.
> >
> > > And yet normal Linux distributions like Fedora, Debian,
> > Ubuntu or openSUSE manage to check their tens of thousands of
> > packages just fine…
> >
> > The following is just my personal opinion on this story in the
> > form of a wall of text[4], in which you can choose to run into
> > or not. Also, it’s not meant to be harsh, even if it reads
> > like this in some parts of it. Just a (hopefully thorough
> > enough) explanation of why it’s a bad idea to have postinst
> > and chmod 666 stuff in /usr/ so that app developers can go
> > back to creating great apps, understanding the reasons for not
> > having postinst scripts and that it’s a Good Thing, and
> > doesn’t conflict with What We’re Used To on Desktop Linux.
> >
> > All the core packages (well, most of them at least) of Fedora,
> > Debian, etc.. are open source in the repositories, built on
> > their servers, and could at least in theory be reviewed by
> > someone. Try to get a package into Fedora or Debian that does
> > “chmod 666” to some directory in /usr/share/ in the postinst
> > script - probably not going to be accepted there.
> >
> > In fact, if you want to go all “Desktop Linux” on this issue,
> > read the FHS[6], and let me quote RedHat’s documentation[7]:
> >
> > “The two most important elements of FHS compliance are: […]
> > The ability to mount a /usr/ partition as read-only."
> >
> > In any case, at least for Debian, here’s the policy page
> > regarding maintainer scripts in case you haven’t read it yet:
> >
> http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
> >
> > Also, have a look at all those nice flow graphs (I especially
> > like the “Upgrading” one) in the Debian wiki related to
> > maintainer scripts (it might be different in the RPM world,
> > but the point is that it’s not as trivial as it sounds
> > initially):
> > https://wiki.debian.org/MaintainerScripts
> >
> > But - we’re neither Debian nor Fedora (nor openSuSE for that
> > matter); and I don’t even know if we comply to the FHS or not
> > - this is Sailfish OS. Don’t say “It’s an RPM system - I know
> > this”[2] while not understanding the subtle points, and that a
> > package in Debian/Fedora is different from an “app” on a
> > mobile device. Where postinst scripts make sense on Debian for
> > system packages, and even where they make sense on Sailfish
> > OS/Mer for system packages (we use postinst scripts there, and
> > for good reasons!), these scripts in almost all cases do not
> > make sense in third-party app packages.
> >
> > If you think your package is that useful and needs to run as
> > daemon and have postinst scripts, chances are you should be
> > trying to get it into Mer or Nemo Mobile, from which it can
> > then be picked up and be installed into the system - possibly
> > even by default (yay!), because it’s so awesome (seriously, if
> > you have such an app/middleware/service, don’t bother getting
> > it into Harbour - get the middleware parts into Nemo Mobile
> > and integrated well, then only push a GUI for it into Harbour
> > [yes, I know that’s more work *for you* and will take “ages",
> > but it will result in something much nicer and saner *for
> > everybody*]).
> >
> > The problem in this thread is that somebody is trying to do
> > something that’s a bad idea in general. The question should
> > not be “How do I make /usr/share/$NAME world-writable?” (that
> > is usually NEVER a good idea), but rather “My app wants to do
> > this and that, my initial approach was to
> > make /usr/share/$NAME world-writable, but that’s not allowed
> > by Harbour, and now that I come to think of it, it’s probably
> > the wrong solution - how would I solve this problem in a way
> > that is acceptable by Harbour and still achieves my
> > goal?” (and if you ask that question, I’ll be more than happy
> > to help ;).
> >
> > By the way, the Harbour rules are not set in stone and up for
> > discussion to be improved and more developer-friendly, so
> > please post any issues that you have here. However, postinst
> > scripts (at the current state where they are run as root at
> > installation time) and world-writable /usr/ are NOT up for
> > discussion (and this very mail tries to explain why).
> >
> > Just for the record, in case it wasn’t clear:
> >
> > - Files in /usr/share/ must not be writable by normal users
> > (guess what? that’s a requirement in Fedora, Debian, etc.. as
> > well!, also it makes debugging so much harder; there’s no way
> > to just “nuke the app’s config in /home/nemo/ to start afresh“
> > if the app might have overwritten, changed or deleted some
> > data in /user/share/ that it also uses at runtime)
> > - RPM packages must not install files to /home/nemo/ (guess
> > what? if you were to install files there on a Fedora/Debian
> > system, it would be pretty, pretty bad for obvious reasons
> > [hint: your username on your Desktop system might not be
> > “nemo”, and your Desktop system might have multiple users, and
> > the numeric UID of the user might be a different one, etc])
> >
> > In addition, don’t forget that:
> >
> > - Deleting files in /usr/share/ doesn’t work, as those files
> > will be re-created each time the package is upgraded
> > - Modifying files in /usr/share/ doesn’t work, as those files
> > will be overwritten each time the package is upgraded
> >
> > (see a pattern there?)
> >
> > The *user* as owner of the device can do whatever he/she
> > pleases (they can be root and mess with the system as much as
> > they want), they are the ones paying for fixing the device in
> > case it’s bricked and needs to be sent to care. The *app* as
> > “guest” on the user’s device should do sane things, and
> > ideally not cause breakage, and ideally not run as root, at
> > least not without the user’s permission - definitely not at
> > installation time without user confirmation.
> >
> > There are still an infinite number of things that a bad app
> > can do, even as “nemo” user, that harbour QA or any amount of
> > manual checking will never be able to catch (hint: google
> > “Static program analysis” and “Halting problem” for a very
> > scientific approach or think about embedding/encrypting shared
> > libraries/executables in your binary and extracting +
> > executing/loading them at runtime for a very practical
> > approach). Those will be catched and dealt with later / when
> > the app is out.
> >
> > Again, the *user* is root on the device, not the *app*. If you
> > install one of my applications, it’s still you who owns the
> > device and has root, not my application - and that is a very,
> > very good thing. It really is. Trust me. Or actually don’t
> > trust me. Because you don’t want my code running as root when
> > my app is installed (I wouldn’t want my code running as root
> > when my app is installed, for that matter).
> >
> > The fact that there might have been some packages in Maemo
> > Extras back in the day that installed files to /home/user/ or
> > even /home/user/MyDocs/ (think about what happens when the
> > device is connected as USB Mass Storage while the package is
> > installed [hint: yeah, MyDocs isn’t mounted during that time])
> > doesn’t necessarily mean that it’s a good idea in general
> > (hint: it really isn’t a good idea, and never was).
> >
> > > BTW, I would be more concerned of closed source binary-only
> > packages being submitted to the store, than about scripts you
> > can actually read.
> >
> >
> > When a user installs an app from the Store, nowhere do they
> > have the chance to read (or even understand) the script. The
> > script can be anything, even calling a closed source binary
> > that’s installed as part of the package. Even if we had the
> > manpower and expertised people in QA that can read, check and
> > understand(!) all postinst scriptlets (even I can’t do that),
> > it would still be a bad idea. Even if the sources were open
> > (hint: open source doesn’t mean readable or understandable
> > code[3]).
> >
> > The fact that the postinst scripts are shell scripts doesn’t
> > have anything to do with “scripts you can actually read” (or
> > understand), of course for the pathological case of “chmod
> > 666” it would be easy to do, but in the general case, it’s
> > not. And it doesn’t change the fact that “chmod 666”
> > in /usr/share/ is still a bad idea.
> >
> > Also, when talking about maintainer scripts, people often
> > forget about upgrading packages —
> > postinst/preinst/postrm/prerm scripts sometimes have to be
> > really really smart about those situations to not mess things
> > up; if you’ve ever upgraded a Debian system, they even have
> > things in place that will try the old postrm (for example)
> > script and fall back to the new one in case the old one fails,
> > because otherwise you’d be stuck with a non-working system
> > (the postrm can never be run -> the package can never be
> > upgraded, or something like that - go checkout the Debian Wiki
> > link from above, it’s complicated).
> >
> > I don’t even know of any other user-friendly mobile platform
> > that allows something like postinst scripts (certainly not as
> > root user). If it’s a good idea, do it and be “unlike”, but if
> > it’s a bad idea, stick to whatever everyone else is doing (be
> > “like”) and/or improve on that with good ideas.
> >
> > > The blob can on the other hand do anything without QA having
> > any reasonable means to check for that.
> >
> >
> > The “blob” is usually run as “nemo” user, which by default has
> > less permissions than the root user (which is the user with
> > which postinst scripts are run). Ideally I’d personally like
> > to see those apps running completely sandboxed - again, not to
> > “close down the system”, but rather to protect you and me -
> > the users - from bad apps (and they don’t even have to be
> > programmed to be bad, it might just be a typo[5] without bad
> > intentions ending up doing something really really bad).
> >
> > Eventually I’d like to be able to download a random RPM
> > package from the web, and install it without checking what’s
> > inside, and still have some degree of certainty that this app
> > won’t do anything bad to my system, or my user data. But
> > again, we’re not there yet, so the Harbour rules try to
> > atleast avoid the obvious places where such problems usually
> > crop up.
> >
> > Again, in my very personal opinion (like everything in this
> > mail), an open device to me means that I *as user* can have
> > root and do everything I want to do, but I don’t want random
> > apps that I install (that includes my own apps) to run as
> > root, not during install time and also not during runtime. if
> > *I* on *my device* decide that it’s a good idea to run app A
> > as root, I can do so from the command line in a root shell or
> > from a GUI app that I installed myself.
> >
> >
> > HTH :)
> > Thomas
> >
> > [1] http://xkcd.com/386/
> > [2] http://www.youtube.com/watch?v=dFUlAQZB9Ng
> > [3] http://www.ioccc.org/
> > [4] http://en.wikipedia.org/wiki/Wikipedia:Wall_of_text
> > [5]
> >
> https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123
> > [6] http://www.pathname.com/fhs/
> > [7]
> >
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s1-filesystem-fhs.html
> > _______________________________________________
> > SailfishOS.org Devel mailing list
> >
> >
> >
> > _______________________________________________
> > SailfishOS.org Devel mailing list
>
>
> _______________________________________________
> SailfishOS.org Devel mailing list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20140111/6f992a47/attachment.html>
More information about the Devel
mailing list