Post by K. Fossil userIn this mailing list we need to know everything about fossil and
fossil related stuffs.
- inetd/xinetd etc. that may be used in conjonction with Fossil (may
be I am the only one who hear about a daemon (inetd) that was used
with Fossil?)
- security related (Fossil is a server sort of)
Let me try to explain this a different way.
The single fossil executable is several distinct things, and compatible
with several distinct technologies. It also has additional features that
can be enabled when building, which are not enabled by default.
Fossil is:
1. A CLI program that as a DVCS uses a local repository to track changes.
2. A client for push/pull/sync with a remote repository
3. A CGI program usable from a big web server
4. A server, for both web and fossil sync, listening on port 80, 8080,
or a configured port.
Case 1 has no external security issues. You are at a command prompt. You
can presumably do anything at all to your own files. Fossil won't
actively help you destroy data any more than GCC does or your favorite
IDE. Naturally it can be misused and could have bugs because we are only
human. This case is exercised by the test suite that is run occasionally
by various developers.
Case 2 can be compiled to use SSL, otherwise it uses sockets in the
clear. Login security and access controls are configured at the server
end. Configuration can be subtle, but for simple open source projects it
can be simple and largely just works.
Cases 3 and 4 (and other subtly distinct variations that most often come
up in some SSL configurations) are all on the server end.
Case 3 is normal CGI. Overall security of the server is the
responsibility of the world-facing web server. This might not be the
"best" way to setup an externally accessible repository, but it is the
easiest. Login security that controls access to the repository itself is
handled by fossil, with a session cookie across transactions. If your
web server already handles SSL, you can get SSL coverage of your
repository essentially for free this way.
Case 4 covers at least three distinct usage styles. It is how the
"fossil ui" command is implemented, essentially by starting a server on
localhost:8080 and launching a web browser to touch it. A long-running
server can be easily set up for a single repository or a directory full
or repositories with the "fossil server" command. You can also use
(x)inetd or another launch and monitor daemon to defer launching fossil
until the port is accessed.
Under most conditions, if fossil happens to find itself running as root,
it enters a chroot jail and drops as much privilege as it can. This
mitigates most attacks that depend on getting something running as root
to misbehave. Fossil doesn't examine the user's request until that is done.
If inetd, xinetd, systemd, or something similar is used to launch fossil
on demand, then that daemon is what is seen first by an attacker. The
biggest concern is that a bug or incident might cause a denial of
service by crashing that super-daemon. That is what happened with
http://fossil-scm.org when you started flogging the inetd is evil horse
recently. The daemon died. The machine didn't notice. Services not
managed by that specific daemon remained alive. This is one of the
problems that systemd is trying to solve: by being more aware of what is
supposed to be running, systemd can notice losses and repair them. Many
people think that is a good idea. Many people are not convinced. Inetd
and its close relatives do less monitoring. But for a resource that is
rarely used, having fossil launch when touched can be a better use of
server resources than having fossil launched, listening, and paged in
when touched.
The bottom line is that fossil does not require the use of inetd,
xinetd, systemd, a web server.
But for systems where the administrator has made her own judgment of the
balance of security, reliability, and other risk factors, the option is
there.
Post by K. Fossil user....
a) I have nothing to ask at this time, so I don't even need to learn how to [ask]
Reasons you sound like a troll.
1. This statement right here. The questions you have asked have shown
very little effort on your part.
2. Fake name. Not all trolls use aliases, sure. But I've seen far fewer
outright trolls using obviously real identities.
3. Belligerence. We support fossil because it is useful to us. You
approach us with a hostile attitude, then get worse when people engage
and try to help.
4. The rest of this email which I'm not responding to in detail.
--
Ross Berteig ***@CheshireEng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602