<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>