[SailfishDevel] Scriptlets in RPM hot allowed to Harbour
Mike Sheldon
mike at mikeasoft.com
Sat Jan 11 16:40:43 UTC 2014
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
More information about the Devel
mailing list