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