exporting from kmail (Was: Kmail2/Akonadi issue on FreeBSD.)

[Duncan]

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

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.

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.

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.

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.

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

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

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

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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