Re: [systemd-devel] How to properly write an "umbrella" unit
On Thu, 23.07.15 10:41, Daurnimator (q...@daurnimator.com) wrote: > On 23 July 2015 at 04:41, Lennart Poettering wrote: > > Maybe we can change the manager core to propagate Reload() calls > > for unit type that do not support it natively to other units listed in > > PropagateReloadsTo= and then become a NOP. > > > > Or in other words: invoking reload on a target that knows no > > PropagateReloadsTo= should continue to return an error. But if such > > deps are defined, it should become a silent NOP and propagate the > > event. > > > > Could you file an RFP issue on github asking for this? [or even better, > > send a PR with a patch... ;-) ] > > ReloadPropagatedFrom= would seem to be more useful here. Well, ReloadPropagateFrom= is the inverse of PropagateReloadsTo=. If there is a dep of the first kind from A to B, there's always a dep of the second kind from B to A, and vice versa. > Why should reloading a target error in the first place? ==> why not just a > NOP? Hides bugs? reloading a target makes no sense, unless you use it for reload propagation. Hence we should generate an error. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
On 23 July 2015 at 04:41, Lennart Poettering wrote: > Maybe we can change the manager core to propagate Reload() calls > for unit type that do not support it natively to other units listed in > PropagateReloadsTo= and then become a NOP. > > Or in other words: invoking reload on a target that knows no > PropagateReloadsTo= should continue to return an error. But if such > deps are defined, it should become a silent NOP and propagate the > event. > > Could you file an RFP issue on github asking for this? [or even better, > send a PR with a patch... ;-) ] ReloadPropagatedFrom= would seem to be more useful here. Why should reloading a target error in the first place? ==> why not just a NOP? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Confusing journal information - journal size
On Fri, 17.07.15 13:13, David Sommerseth (dav...@redhat.com) wrote: > > Hi, > > I'm looking through some journals now, and even though I've seen it a > few times I haven't thought about it until now. > >systemd-journal[1151]: Runtime journal is using 8.0M (max allowed > 4.0G, trying to leave 4.0G free of 63.7G available → > current limit 4.0G). > > Could this line be cleaned up so you don't have to look up a man page to > try to figure out what this really means? Here's my uneducated guess > and confusion of this line: > > * Runtime journal is using 8.0M > - Okay, so currently the journal uses 8MB of disk-space. No problem. > > * max allowed 4.0G > - Okay, so the journal should not grow beyond 4GB, makes sense. No > problem. > > * trying to leave 4.0G free of 63.7G available > - Uhm, what!? So it will grow until there is 4GB left on the > filesystem? Not so okay. > > * current limit 4.0G > - Ehh ... okay ... so make up your mind, please! So will the > journal grow until 4GB or 59.7GB. > > > But then I looked into /var/log/journal ... > > # du --si -s /var/log/journal/ > 4.3G/var/log/journal/ > > I do see that both system,journal and user-UID.journal are both 8.4MB, > and from that I can guess what the log entry tried to tell me with > "Runtime journal" ... but how is /that/ information useful for me, from > a sys-admin point of view? > > My point is ... you're providing too much information and you need to > understand more underlying things about the journal. Simply state how > much disk-space the journal uses now and how much it will grow. Period. > Don't do any "we can grow until size X, but decided to grow to Y > instead" information. Well, you might not find this information useful, others however will. These are logs, and I think it's a good idea to be rather slightly too verbose than slightly too little verbose. Hence I think that this information should continue to be shown. It's not pages and pages of rubbish after all, just a single log message shown on very few occasions. That siad, I have now reworded things a bit, to make this easier to grok: https://github.com/systemd/systemd/pull/665 With that change you'll see a message like this: systemd-journal[1151]: Runtime journal (/run/log/journal) is currently using 8.0M. Maximum allowed usage is set to 4.0G. Leaving at least 4.0G free (of currently available 63.7G disk space). Enforced usage limit is thus 4.0G. I hope this clears things up a bit. If you still find this too confusing, send a patch, and please explain why the bikeshed looks better in green. Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Use of capabilities in default service files
On Tue, 21.07.15 13:24, Florian Weimer (fwei...@redhat.com) wrote: > And that's fine. But doing hardening for UID=0 services seems a very > bad practice to me because it looks like someone is assuming that UID=0 > without capabilities is just another “nobody” user. Which is not > surprising, because capabilities are often advertised that way. I'd be happy to take a patch that adds a comment about this to the CapabilityBoundingSet= option in the man page, explaining that one should not mistake a UID=0 user zero caps as equivalent to a nobody user. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Use of capabilities in default service files
B1;4002;0cOn Mon, 20.07.15 13:58, Florian Weimer (fwei...@redhat.com) wrote: > On 07/20/2015 01:52 PM, Reindl Harald wrote: > > > > > > Am 20.07.2015 um 13:24 schrieb Florian Weimer: > >> CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP > >> m4_ifdef(`HAVE_SMACK', CAP_MAC_ADMIN ) > >> … > >> What's the intent of these settings? Is it a form of hardening? If > >> yes, it is rather ineffective because UID=0 does not need any > >> capabilities to completely compromise the system. > > > > UID=0 *does* need capabilities, > > drwxr-xr-x. 2 root root 37 Jun 13 10:09 /etc/cron.d > -rw-r--r--. 1 root root 3068 Jul 17 19:47 /etc/passwd > > UID=0 without CAP_DAC_OVERRIDE (or any other capabilities) can write to > these locations and escalate fairly directly to full root. This could (and should) be combined with ProtectSystem=full to make this effective. Also, if the web server drops UID, then the bounding set has the benefit that none but the specified caps can be reacquired via SUID binaries or fcaps executables. Again, caps do not exist in a vacuum. They are useful in conjunction with other mechanisms, both within systemd, and in the daemons themselves. > > that's the whole purpose of > > CapabilityBoundingSet and so yes it is a form of hardening > > To me, it looks someone misunderstood the interactions between UID=0 and > capabilities. To me, it looks someone misunderstood that capabilities can be combined with other mechanisms. ;-) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Use of capabilities in default service files
Am 21.07.2015 um 13:24 schrieb Florian Weimer: On 07/20/2015 02:34 PM, Reindl Harald wrote: Am 20.07.2015 um 13:58 schrieb Florian Weimer: On 07/20/2015 01:52 PM, Reindl Harald wrote: Am 20.07.2015 um 13:24 schrieb Florian Weimer: CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP m4_ifdef(`HAVE_SMACK', CAP_MAC_ADMIN ) … What's the intent of these settings? Is it a form of hardening? If yes, it is rather ineffective because UID=0 does not need any capabilities to completely compromise the system. UID=0 *does* need capabilities, drwxr-xr-x. 2 root root 37 Jun 13 10:09 /etc/cron.d -rw-r--r--. 1 root root 3068 Jul 17 19:47 /etc/passwd UID=0 without CAP_DAC_OVERRIDE (or any other capabilities) can write to these locations and escalate fairly directly to full root. why should it need CAP_DAC_OVERRIDE when it *owns* the files and has write permissions? Exactly, it's the reason why I suspect something fishy is going on if people to harden services running UID=0 by taking away capabilities. the point of hardening is to make it more difficult that a machine could get owned with a exploit - there is no 100% secure - you just want make things as difficult as possible chown the file to a different user and root no longer can write there to protect /etc and /usr "ReadOnlyDirectories" is the way to go ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr Then you still have instant root through: have fun on our httpd. and no, i did not add "InaccessibleDirectories=-/var/spool" now, it's there for years [Unit] Description=Apache Webserver After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple EnvironmentFile=-/etc/sysconfig/httpd Environment="PATH=/usr/bin:/usr/sbin" ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful Restart=always RestartSec=1 UMask=006 PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX AF_NETLINK AF_PACKET AF_X25 SystemCallArchitectures=x86-64 ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib ReadWriteDirectories=-/var/lib/smokeping InaccessibleDirectories=-/boot InaccessibleDirectories=-/home InaccessibleDirectories=-/media InaccessibleDirectories=-/root InaccessibleDirectories=-/etc/dbus-1 InaccessibleDirectories=-/etc/modprobe.d InaccessibleDirectories=-/etc/modules-load.d InaccessibleDirectories=-/etc/postfix InaccessibleDirectories=-/etc/ssh InaccessibleDirectories=-/etc/sysctl.d InaccessibleDirectories=-/run/console InaccessibleDirectories=-/run/dbus InaccessibleDirectories=-/run/lock InaccessibleDirectories=-/run/mount InaccessibleDirectories=-/run/systemd/generator InaccessibleDirectories=-/run/systemd/system InaccessibleDirectories=-/run/systemd/users InaccessibleDirectories=-/run/udev InaccessibleDirectories=-/run/user InaccessibleDirectories=-/usr/lib64/dbus-1 InaccessibleDirectories=-/usr/lib64/xtables InaccessibleDirectories=-/usr/lib/dracut InaccessibleDirectories=-/usr/libexec/iptables InaccessibleDirectories=-/usr/libexec/openssh InaccessibleDirectories=-/usr/libexec/postfix InaccessibleDirectories=-/usr/lib/grub InaccessibleDirectories=-/usr/lib/kernel InaccessibleDirectories=-/usr/lib/modprobe.d InaccessibleDirectories=-/usr/lib/modules InaccessibleDirectories=-/usr/lib/modules-load.d InaccessibleDirectories=-/usr/lib/rpm InaccessibleDirectories=-/usr/lib/sysctl.d InaccessibleDirectories=-/usr/lib/udev InaccessibleDirectories=-/usr/local/scripts InaccessibleDirectories=-/var/db InaccessibleDirectories=-/var/lib/dbus InaccessibleDirectories=-/var/lib/dnf InaccessibleDirectories=-/var/lib/rpm InaccessibleDirectories=-/var/lib/systemd InaccessibleDirectories=-/var/lib/yum InaccessibleDirectories=-/var/spool [Install] WantedBy=multi-user.target signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Use of capabilities in default service files
Am 20.07.2015 um 13:24 schrieb Florian Weimer: CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP m4_ifdef(`HAVE_SMACK', CAP_MAC_ADMIN ) … What's the intent of these settings? Is it a form of hardening? If yes, it is rather ineffective because UID=0 does not need any capabilities to completely compromise the system. UID=0 *does* need capabilities, that's the whole purpose of CapabilityBoundingSet and so yes it is a form of hardening http://linux.die.net/man/7/capabilities our internal httpd package is using the following options and when you remove CAP_NET_BIND_SERVICE it could not bind to port 80, PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Use of capabilities in default service files
Am 20.07.2015 um 13:58 schrieb Florian Weimer: On 07/20/2015 01:52 PM, Reindl Harald wrote: Am 20.07.2015 um 13:24 schrieb Florian Weimer: CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP m4_ifdef(`HAVE_SMACK', CAP_MAC_ADMIN ) … What's the intent of these settings? Is it a form of hardening? If yes, it is rather ineffective because UID=0 does not need any capabilities to completely compromise the system. UID=0 *does* need capabilities, drwxr-xr-x. 2 root root 37 Jun 13 10:09 /etc/cron.d -rw-r--r--. 1 root root 3068 Jul 17 19:47 /etc/passwd UID=0 without CAP_DAC_OVERRIDE (or any other capabilities) can write to these locations and escalate fairly directly to full root. why should it need CAP_DAC_OVERRIDE when it *owns* the files and has write permissions? chown the file to a different user and root no longer can write there to protect /etc and /usr "ReadOnlyDirectories" is the way to go ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [root@srv-rhsoft:~]$ cat /etc/systemd/system/test3.service [Unit] Description=Test Unit [Service] Type=oneshot ExecStart=/usr/bin/touch /etc/passwd PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=CAP_NET_BIND_SERVICE [Install] WantedBy=multi-user.target Jul 20 14:25:59 srv-rhsoft touch: /usr/bin/touch: „/etc/passwd“ kann nicht berührt werden: Keine Berechtigung Jul 20 14:25:59 srv-rhsoft systemd: test3.service: main process exited, code=exited, status=1/FAILURE Jul 20 14:25:59 srv-rhsoft systemd: Failed to start Test Unit. that's the whole purpose of CapabilityBoundingSet and so yes it is a form of hardening To me, it looks someone misunderstood the interactions between UID=0 and capabilities. no, the reason starting Apache (as example) with CAP_DAC_OVERRIDE is that the master process needs it to read certificate files which are not readable by the user it uses after start our internal httpd package is using the following options and when you remove CAP_NET_BIND_SERVICE it could not bind to port 80, PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID Without code in the daemon to switch away from UID=0, this is not a very strong restriction (but CAP_DAC_OVERRIDE is root-equivalent anyway, so it probably does not matter). Apache does the switch away from UID=0 I found the “CapabilityBoundingSet=” line (empty set) somewhat worrying, it seems to me that this service should use a separate UID, not 0 that's a different story and works for services wich don't need to read files only readable by root and not listening on privileged ports like mysqld and in that case even if there is a root exploit CapabilityBoundingSet would reduce the damage [Service] Type=simple User=mysql Group=mysql RuntimeDirectory=mysqld RuntimeDirectoryMode=0750 ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/run/mysqld/mysqld.pid ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutSec=300 LimitNOFILE=infinity LimitMEMLOCK=infinity OOMScoreAdjust=-1000 PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_DAC_OVERRIDE CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE RestrictAddressFamilies=~AF_APPLETALK AF_ATMPVC AF_AX25 AF_IPX AF_NETLINK AF_PACKET AF_X25 SystemCallArchitectures=x86-64 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Use of capabilities in default service files
On Mon, 20.07.15 13:24, Florian Weimer (fwei...@redhat.com) wrote: > What's the intent of these settings? Is it a form of hardening? If > yes, it is rather ineffective because UID=0 does not need any > capabilities to completely compromise the system. Well, we run our stuff with minimal attack surface. While the caps stuff is not a complete sandbox, we should take away all privs we can. In particular since many of the caps become useful as soon as you combine them with other options we have, for example PrivateNetwork=yes, PrivateDevices=yes, ProtectSystem=yes and PrivateTmp=yes. Because in that case, write access to root-owned files is quite restricted by other means than just plain access modes... Of course, even then the sandbox will still have many holes, but I am happy to improve things where it makes sense. For example, I'd love it if "hidepid=" would become a true mount option for /proc that we can set differently for each namespace. Because then we could take away access to other root-owned processes from a service running as root. Long story short: the caps bounding set is one piece in a bigger puzzle. As the only puzzle piece they are pretty shitty, but if you put them together with others they'll turn into a pretty picture. And while not all pieces for the complete puzzle might be in the game yet, we should put the ones together we already possess. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
On Wed, 22.07.15 20:28, Michael Biebl (mbi...@gmail.com) wrote:
> 2015-07-22 19:15 GMT+02:00 Lennart Poettering :
> > On Tue, 21.07.15 13:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> >> Can I write my nifty.target as a service? I have seen in this case
> >> nifty.service files with Exec=/bin/true to basically create a no-op
> >> service, but that's ugly.
> >
> > That's a hack. A target is for grouping things, they basically are
> > services without processes attached to them. You really should use
> > targets for this, and not misuse services.
>
> Afaik, there is no way to have a .target reloaded and that reload
> request propagated to all services in that target.
>
> Say you have foo.target consisting of bar.service and baz.service,
> how can you achieve that
> systemctl reload foo.target propagates that reload request to
> {bar,baz}.service?
You cannot do that right now, and I am not sure you should be able to,
after all the operation does not really apply to target units.
I do see your usecase though...
Humm...
Maybe we can change the manager core to propagate Reload() calls
for unit type that do not support it natively to other units listed in
PropagateReloadsTo= and then become a NOP.
Or in other words: invoking reload on a target that knows no
PropagateReloadsTo= should continue to return an error. But if such
deps are defined, it should become a silent NOP and propagate the
event.
Could you file an RFP issue on github asking for this? [or even better,
send a PR with a patch... ;-) ]
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
2015-07-22 19:15 GMT+02:00 Lennart Poettering :
> On Tue, 21.07.15 13:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
>> Can I write my nifty.target as a service? I have seen in this case
>> nifty.service files with Exec=/bin/true to basically create a no-op
>> service, but that's ugly.
>
> That's a hack. A target is for grouping things, they basically are
> services without processes attached to them. You really should use
> targets for this, and not misuse services.
Afaik, there is no way to have a .target reloaded and that reload
request propagated to all services in that target.
Say you have foo.target consisting of bar.service and baz.service,
how can you achieve that
systemctl reload foo.target propagates that reload request to {bar,baz}.service?
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Sat, 18.07.15 19:06, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > On Tue, Jun 09, 2015 at 01:02:43PM +0200, Lennart Poettering wrote: > > On Mon, 01.06.15 22:43, Michael Biebl (mbi...@gmail.com) wrote: > > > > > 2015-06-01 20:12 GMT+02:00 David Herrmann : > > > > Hi > > > > > > > > As of today we've disabled git-push to fd.o. The official development > > > > git repository is now at github [1]. > > > > > > What about the bug tracker? Will it remain at fdo's bugzilla. I have > > > to admit I'm not a huge fan of github's bug tracker. > > > > I am not a fan of bz either... > > > > I think for now we prefer github, but will leave bz open, and we will > > not migrate bugs. > > As it looks at the moment, freedesktop.org doesnt want new bugs to be > filed in their Bugzilla. At least it is no longer possible to open new > bugzilla requests for systemd there. > > Would you prefer bugzilla requests to be moved over to github issues > by people interested in those requests/issues being addressed, or do > old bugzilla requests have the same chance of being looked at by > somebody able to address them as github issues? As mentioned before: please do not migrate bugs. We will track old bugs on fdo, and new bugs on github. Developers will continue to look at both places. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does socket activation block a TCP port for listening by other processes?
On Tue, 21.07.15 16:39, Florian Weimer (fwei...@redhat.com) wrote: > On 07/21/2015 01:52 PM, David Herrmann wrote: > > Hi > > > > On Tue, Jul 21, 2015 at 1:37 PM, Florian Weimer wrote: > >> We have quite a zoo of services which listen on localhost, on a fixed > >> TCP port, for use by local clients. The canonical example is PostgreSQL > >> on 5432/TCP, for the benefit of Java clients (which cannot use the UNIX > >> domain socket). This has the obvious issue that if a local attacker > >> crashes the service, they can impersonate it by binding to the same port. > >> > >> Does socket activation reliably prevent such impersonation attacks? Or > >> is there race, say during systemd configuration reloading or service > >> restarts, where systemd temporarily does not listen to that port? > > > > This "race" *does* exist with socket activation. The sockets may be > > re-created if the unit transitions between states (like restart). > > Thanks. Would it make sense to fix this in some way, so that the socket > sticks around? I don't think that would be a good idea. If you restart a .socket unit, then we really should do that, because the user asked us to do so. The restart operation does not do anything besides closing the sockets and reopning it with the new configuration. If the user asks us to restart we should hence do that. > > And please note, the actual activated > > unit usually does *not* have rights to bind the socket. This is done > > by pid1. So an attacker would require rights of PID1 for such an > > attack. > > unconfined_t unfortunately has this right for port numbers larger than > 1023, unfortunately. We are working on hooking up the firewall with systemd units, so that you can write firewall rules that apply specifically to certain units. That sounds like a better way to lock certain services to specific ports. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does socket activation block a TCP port for listening by other processes?
On Tue, 21.07.15 13:37, Florian Weimer (fwei...@redhat.com) wrote: > We have quite a zoo of services which listen on localhost, on a fixed > TCP port, for use by local clients. The canonical example is PostgreSQL > on 5432/TCP, for the benefit of Java clients (which cannot use the UNIX > domain socket). This has the obvious issue that if a local attacker > crashes the service, they can impersonate it by binding to the same port. > > Does socket activation reliably prevent such impersonation attacks? Or > is there race, say during systemd configuration reloading or service > restarts, where systemd temporarily does not listen to that port? There are things like SO_REUSEADDR that allow privileged apps to bind to addresses/ports that something else is already listening on. Ignoring that, yes, systemd will listen on the socket as long as the .socket unit is up, and that might be longer than the service unit, even if it crashes. If you restart the .socket unit, then there will be window where the socket is not connectable of course, and something else might bind it, even without SO_REUSEADDR. Restarting a .socket window is necessary if you change the settings of .socket unit in any way, maybe to chnage which port or ip address you want it to listen on, or to change a socket parameter. Reloading/reexecing systemd itself will keep all sockets it is listening on open, it will pass the open socket fds from the old to the new systemd process without closing them in between. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
On Tue, 21.07.15 13:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > Hi, > > I am trying to systemd'ize a daemon which is useful to be run in two > instances. It is usually the case that both instances need to be > started and stopped simultaneously, and the local admin would want a > _single_ command to start and stop both instances. Therefore, an > "umbrella" is needed. > > As a beginner, I have written: > > nifty.target: > [Unit] > Description=nifty Server (all protocols) > After=network.target Unrelated to the actual topic of this thread: this line above usually doesn't do what people assume it does: It does not start the daemon after the network is up -- which is what most folks might think --, that's what network-online.target is for. Also, most daemons actually don't need the network to be up, and it is bad style to make daemons wait for external events such as DHCP events anyway. Hence, don't use this. The primary effect of ordering something after network.target is actually at shut down, since it ensures that the service is stopped before the network is turned off.) It is usually a good to remove such lines, unless you really really know you need it. In this case the target should definitely not list this, if at all the services should, but probably not even they. > This works as designed. Unfortunately, my Distribution's build tools > don't handle package-provided targets too well, and I feel that using > a target here is kind of wrong anyway. Going for a target for this sounds like the right choice, and if your distro cannot support that nicely, it really should be improved to support it. > Can I write my nifty.target as a service? I have seen in this case > nifty.service files with Exec=/bin/true to basically create a no-op > service, but that's ugly. That's a hack. A target is for grouping things, they basically are services without processes attached to them. You really should use targets for this, and not misuse services. > If I move my service to a nifty@.service, how would I start two > instances from a single shell command? You can also group instances with a target unit nicely. But the way to group things is via target units, nothing else. > How would one handle this situation in the clear, recommended way? The way you already did it! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] c/c++ lib for dbus
On Mon, 20.07.15 17:09, Pradeepa Kumar (cdprade...@gmail.com) wrote: > Hi > I need to use functions to call method, get property value etc from > dbus. See http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html and have a look at the sd-bus.h header file: https://github.com/systemd/systemd/blob/master/src/systemd/sd-bus.h To read properties we have the sd_bus_get_property() and related convencience functions. There's currently no nice documentation available for them, hence consult the sources of systemd for details. > also few utility functions like unit_name_from_dbus_path() from > systemd. This is an internal function of systemd, and is not part of any API. It should not be used in external programs. > Can i use systemd as lib ? If yes how , where can I see examples? > is there any lib for that in c /c++? The systemd D-Bus API "sd-bus.h" is a public API now, see the blog story linked above. Along with some other APIs it is exported by libsystemd.so. However, calls like unit_name_from_dbus_path() are not part of that library and not accessible externally. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd
On Wed, Jul 22, 2015 at 04:17:36PM +0800, Xtonic wrote: > Hi, > > I am new to systemd. I am using CoreOS 717.3.0 with systemd 220. > > > When I checked the status of systemd-networkd I got: > > systemctl status systemd-networkd > > ● systemd-networkd.service - Network Service > >Loaded: loaded (/usr/lib64/systemd/system/systemd-networkd.service; > disabled; vendor preset: disabled) >Active: inactive (dead) since Tue 2015-07-21 16:34:31 UTC; 1h 50min ago > > I had no problem with the network, is it normal? That's norma; behaviour, introduced in v219 https://github.com/systemd/systemd/blob/master/NEWS#L629 : * networkd now exits when idle. It will be automatically restarted as soon as interfaces show up, are removed or change state. networkd will stay around as long as there is at least one DHCP state machine or similar around, that keep it non-idle. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd
Hi, I am new to systemd. I am using CoreOS 717.3.0 with systemd 220. When I checked the status of systemd-networkd I got: systemctl status systemd-networkd ● systemd-networkd.service - Network Service Loaded: loaded (/usr/lib64/systemd/system/systemd-networkd.service; disabled; vendor preset: disabled) Active: inactive (dead) since Tue 2015-07-21 16:34:31 UTC; 1h 50min ago Docs: man:systemd-networkd.service(8) Process: 483 ExecStart=/usr/lib/systemd/systemd-networkd (code=exited, status=0/SUCCESS) Main PID: 483 (code=exited, status=0/SUCCESS) Status: "Shutting down..." No error found in journald and I tried to restart the service a number of times, it would stay in ""Processing requests..." for a while and back to "Shutting down..." I had no problem with the network, is it normal? David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
On Tue, Jul 21, 2015 at 09:42:38PM +0200, Michael Biebl wrote: > Have a look at the openvpn package in Debian. It implements something > like you have in mind. > There are multiple openvpn@.service instances and a single > openvpn.service which can be used by the admin to start/stop/restart > them. That uses a generator, which is somewhat oversized for the question at hand. And it's a service with ExecStart=/bin/true which is a hackish workaround. But if that's the way to go, I'm fine with it. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
