[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