Hi, Sorry, I forgot about PackageKit! ;) I was still in the apt world :)
Regards, -- Marcin 2014/1/11 Mike Sheldon <m...@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.p...@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.kol...@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 >
_______________________________________________ SailfishOS.org Devel mailing list
