<div dir="ltr"><div><div>Hi,<br><br></div>Sorry, I forgot about PackageKit! ;) I was still in the apt world :)<br><br></div>Regards,<br></div><div class="gmail_extra"><br clear="all"><div><div>--</div>Marcin<br></div>
<br><br><div class="gmail_quote">2014/1/11 Mike Sheldon <span dir="ltr"><<a href="mailto:mike@mikeasoft.com" target="_blank">mike@mikeasoft.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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


>         _______________________________________________<br>
>         SailfishOS.org Devel mailing list<br>
><br>
><br>
><br>
> _______________________________________________<br>
> SailfishOS.org Devel mailing list<br>
<br>
<br>
_______________________________________________<br>
SailfishOS.org Devel mailing list</div></div></blockquote></div><br></div>