exporting from kmail (Was: Kmail2/Akonadi issue =?windows-1256?q?on=09FreeBSD=2E?=)

[gene heskett]

On Saturday, December 03, 2011 02:07:30 PM Duncan did opine:

> [Given that you are in recovery, save this to come back to later, if
> needed.]
> 
> gene heskett posted on Sat, 03 Dec 2011 06:39:55 -0500 as excerpted:
> > On Saturday, December 03, 2011 06:23:58 AM Duncan did opine:
> >> gene heskett posted on Fri, 02 Dec 2011 13:06:19 -0500 as excerpted:
> >> >> As I've mentioned previously, claws-mail uses a Unix socket for
> >> >> instance syncing.
> >> > 
> >> > But where is the sockets # defined?
> >> 
> >> I don't quite get the thrust of that question
> >> 
> >> It's a Unix socket, so it's defined by a path and socketfile name,
> >> not an IP and port number, so socket number doesn't really make
> >> sense
> >> 
> >> Be that as it may, the socket path and filename is...
> >> 
> >> $TMPDIR/claws-mail-<UID>
> > 
> > Humm, I have:
> > [gene at coyote ~]$ ls $TMPDIR
> > claws-mail-0=
> > 
> > But a cat, or an ls -l fails, no such file
> > But an 'ls -l $TMPDIR/' shows it as
> > srwxr-xr-x 1 root   root       0 Nov  3 23:39 claws-mail-0=
> > 
> > So I presume it is usable, by root only.  claws isn't running so
> > should that not have been cleaned up by its exit code?
> 
> You're running (ran?) claws as root? <shudder>
> 
Yeah scary.  But I don't ever recall starting it as anyone but me.

> As the paraphrase goes, "Thou shalt not take the name of root in vain!"

:)
 
> FWIW, I haven't run X while logged in as root (which I seldom do either,
> now days, referring to logging in as root, I just first sudo to my admin
> user with sudo-everything-no-password rights, and then sudo whatever
> command... tho I do still sudo bash for a couple commands from said
> admin user occasionally, in ordered to properly set environmental
> variables and not have them stripped and set to defaults by the sudo
> itself, and I do sudo mc and ctrl-o from there, thus having a root
> shell, occasionally) in so long, I'm no longer sure what would happen
> if I tried.  And while I / did/ recently try to kdesudo some command
> recently, while in kde as my normal user, that didn't work due to
> broken Xauth (talking about Unix sockets, that is one...), and I didn't
> even bother tracking that down, either... I took it as encouragement to
> quit trying to bend my own security rules, instead.

Generally good advice, and I am not allergic to chowning -R, stuff I have 
built in the /home/gene tree.
 
> So basically, only CLI (and ncurses type semi-guis such as mc) will even
> run from a normal user X session now, and I since I haven't run X as
> root in probably half a decade or more, that means no X apps at all
> ever get run as root any more, here.  And like I said, when I tried
> running something x-based as root the other day and it failed, I simply
> took that as encouragement not to bend my own security rules and did it
> the normal way, sudo to my admin user in a konsole session, and from
> there "sudid" <g> whatever I was going to do as root, at the konsole
> CLI, as I should have done in the first place!

:)
 
> It just seems so strange and foreign to even /think/ of running an X app
> as root to me now, that when I tried it the other day and failed, my
> reaction was to more or less guiltily slink back in my hole as if the
> police had just knocked on the steamed up car window! =8^0
> 
> Given that, I guess I feel a bit like that policeman myself, at this
> point, knocking on your window.  Do I need to go find some paperwork to
> do for about five minutes or something? =8^0
> 
> 
> Anyway...
> 
> I did just verify here that my claws-mail sockets get cleaned up when I
> quit claws-mail, and come back when I restart, so yes, they normally do
> get cleaned up.  However, it's worth noting that unlike say TCP/IP
> sockets, Unix sockets are actual files on the filesystem, and if an app
> crashes while they're open, they'll stay around just as would any other
> file when an app crashes -- they won't be cleaned up by the kernel
> basically automatically, as would memory resources and TCP/IP sockets.
> 
> So either that root claws-mail instance was still running, or it had
> crashed without getting a chance to clean up the socket-file it left
> behind.

That may be a possibility, its a month old now and short term memory is one 
of the casualties at my age.
 
> It's worth noting at this point that claws-mail does have a systray
> plugin, and can be set to minimize-to-tray, with the window close button
> then minimizing to tray instead of quitting, and there's an option to
> start-minimized as well.  Depending on your distribution's default
> claws- mail config, it may be that's enabled by default, and when you
> started it as root, it either started in the tray or you hit the close
> button and it minimized to tray instead of quitting.  And, if you
> started it as root from a normal user X-session, I really don't know
> what it might do, in terms of trying to run in a root tray that's not
> there.  Perhaps it was still running as root, and whatever you used to
> tell you whether it was running or not didn't report on the root-user
> claws-mail process that was still there, hidden.
> 
> Or maybe it just crashed and left that file behind.
> 
> Regardless, however, the socket-file name is claws-mail-0 (the = suffix
> being a shorthand indicator for a socket, just as a / suffix indicates a
> directory, etc), while claws-mail run as a normal user, even with
> $TMPDIR set to the same directory (presumably /tmp/ or possibly
> /var/tmp/ if it's shared) would use a filename with a different user-id
> appended, so there should be no conflict and a normal user should be
> able to start claws- mail just fine, creating a claws-mail-* file where
> * is the appropriately different UID.
> 
> And cat-ing a Unix socket... like cat-ing most device-files (other than
> /dev/zero and /dev/null), other than for occasional debugging (cat-ing
> /dev/mouse and wiggling the mouse to see if you get anything or not, for
> instance), is not something you'd normally do from a shell, as the
> output could easily contain control chars, etc, that could mess up the
> shell. Additionally, like a pipe, you can't expect any output unless
> there's something doing input, and AFAIK, many sockets including this
> one are simply listen sockets, until they get some input to reply to. 
> So you can't expect much from cat-ing it.

As I found but its been a useful tool when trying to see if my ups is doing 
its usual slow data stream etc.

> Of course if you read the sources, presumably you find some comments on
> the protocol, and could write something appropriate (presumably a
> command) to the socket and watch for a reply (presumably a status code
> of some sort), but without the sources (or specs, for standard sockets
> like the X-protocol sockets), whether that's ASCII or binary, etc,
> isn't something you'd know.

I did grep the src tree, unsuccessfully.
 
> >> Hope that answers the question...
> > 
> > It points out that I don't know a thing about unix sockets I think. :)
> > 
> > Can you recommend some reading, URL style?  For when I can see well.
> > This morning both eyes have waterlogged bags under them, but this
> > should be the worst of it.
> 
> Off-hand?  Not really, but...
> 
> I don't think I actually formerly learned about Unix sockets anywhere,
> myself.  I think I just sort of picked it up by osmosis, observing
> normal Unix socket usage over the years, plus listings in things like
> mc, which display device major and minor numbers for them, but nothing
> but the usual file info and the = socket symbol for Unix sockets, thus
> more or less indicating that there's no identifiable port number
> characteristics or the like, that could be displayed.

Like named pipes?
 
> But now that you ask, you've prompted me to take a look, confirming and
> adding to my own understanding as well. =:^)
> 
> Wikipedia:  http://en.wikipedia.org/wiki/Unix_socket
> 
> That by itself is little more than a stub, but the external links at the
> bottom are somewhat more useful.  Specifically, this one, a 2005 reply
> to a question on one of the free-bsd lists about the difference between
> unix domain sockets and internet sockets (watch the wrap):
> 
> http://lists.freebsd.org/pipermail/freebsd-performance/2005-
> February/001143.html
> 
> The big takeaways are (included here mainly to reinforce my own
> understanding, since you could read the above just as I just did):
> 
> 1) Unix sockets are local-only, thus don't have the global security
> implications of internet sockets.  An internet socket listening on
> localhost is fine, but are you *REALLY* sure it's limited to listening
> *ONLY* on localhost?  Using Unix socket's that's simply not an issue.
> OTOH, internet sockets give you the flexibility of doing it over a
> network if necessary, even if the normal setup is a localhost socket.
> 
> 2) No IP and port number for Unix sockets.
> 
> 3) Unix sockets use the standard POSIX filesystem namespace, thus are
> subject to all the usual POSIX file permissions (and post-crash file
> cleanup issues), with the usual implications.  If your webserver runs as
> a different (hopefully non-root <clears throat>) user, even if it's
> running on the same machine, it can't access Unix sockets owned by a
> different user unless the socket-file (and the path to it) permissions
> allow it.  Of course, on SELinux systems or the like, there's even
> stronger filesystem access restrictions.
> 
> 4) Performance considerations:  Unix sockets don't have all the IP stack
> overhead and thus can be rather more efficient.  (Keep in mind, however,
> that the specifics here were written from a 2005 FBSD perspective. 
> Linux at least has had quite a bit of IP-stack revisions since then,
> with 10- gig Ethernet and higher in mind.  But regardless, there's
> going to be /some/ additional overhead to the IP-socket method used on
> localhost, because the knowledge that it /is/ localhost is deliberately
> restricted, so the apps can deal with IP sockets transparently either
> way, without having to worry about whether it's local or not.)
> 
> That #1 factor, Unix sockets enforces local-only, is a good reason to,
> for instance, setup your X server to listen on Unix ports only, not the
> traditional IP port, if you know that you're not going to be doing any
> network-transparent X-protocol forwarding and thus know you're not going
> to need that transparency.  If it's not listening on a network port in
> the first place, then there's no chance a cracker can get in on that
> network port since nothing's there listening to even try to process his
> requests.  If a wave breaks on the shore and nobody's there to hear or
> see it it, did it happen?  If a cracker attempts to break in and there's
> nothing listening on that port, hear, and no firewall to log the
> attempt, see, did it happen?  (I was going to use the more familiar
> tree falling in the forest question, but decided the continuous waves
> breaking on the shore was the closer analogy to now ubiquitous crack
> attempts.)
:)
 
> Additionally:
> 
> 5) Unix sockets, like IP-sockets, are two-way, what one might use if one
> wanted a two-way pipe or FIFO (named pipe).

Gotcha.
 
> 6) Unix sockets, unlike IP-sockets, can be byte-stream or datagram
> oriented.

Yes, I'll save this for future reference when I can see with a bit less 
effort.  Thank you very much, Duncan.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
The inherent vice of capitalism is the unequal sharing of blessings;
the inherent virtue of socialism is the equal sharing of misery.
		-- Churchill
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.