[systemd-devel] Service always started as root
Hello, I've configured a service which should start as a specific user. But the service is always started as root. Here is my service-file: [Unit] Description=Autologin After=getty.target [Service] ExecStart=/usr/bin/autologin PAMName=login Name=daniel Group=users [Install] WantedBy=multi-user.target The service starts as expected, but as user root. The script /usr/bin/autologin starts an X-Server on vt08, the script has permissions 744. Any ideas why the service is started as root? Regards Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email d...@marco.de Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service always started as root
On Mon, Oct 7, 2013 at 10:40 AM, Daniel Spannbauer d...@marco.de wrote: Hello, I've configured a service which should start as a specific user. But the service is always started as root. Here is my service-file: [Unit] Description=Autologin After=getty.target [Service] ExecStart=/usr/bin/autologin PAMName=login Name=daniel There is no such directive as Service.Name -- if you want to specify the username, you need Service.User instead: [Service] User=daniel Group=users See the systemd.exec and systemd.directives manual pages. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cross-building systemd?
Warpme war...@o2.pl writes: Hi, I want to build sytemd in cross-build environment. One from many needed dependencies is libcap which is really old and isn't cross-build friendly. It looks like libcap-ng is kind of successor and I can build this lib in my cross-build environment. Is there any way to build systemd with libcap-ng ? Or maybe there is possibility to build systemd without libcap? Thx in advance! We cross-compile libcap and systemd, and it works fine. My rules for building libcap are: make CC=cross-cc BUILD_CC=gcc LIBATTR=no PAM_CAP=no make CC=cross-cc BUILD_CC=gcc LIBATTR=no PAM_CAP=no DESTDIR=somewhere prefix= install We also set quite a few variables (CROSS_COMPILE, LD, AR, CFLAGS, whatever) in our build system, so you might need some of those. They are all set in a pretty standard way. We build libcap from the latest in git (056ffb0bd2). -- Henrik Grindal Bakken h...@ifi.uio.no PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
I got two systems having the exact same problem with similar symptoms. Both systems are upgraded to latest Arch Linux, and just recieved Linux Kernel 3.11.4 upgrades also. One is running on Linode, one is a local machine. Apparently, the fix provided by Auke does not resolve the problem. Tom Gundersens' one, though, does it. Two problems still remain, though: 1. The dbus notice message upon logging in (Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory). 2. The SFTP problem - upon restart, the SFTP connection is not killed. On 5 October 2013 01:46, Tom Gundersen t...@jklm.no wrote: On Fri, Oct 4, 2013 at 8:57 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Fri, Oct 4, 2013 at 9:37 AM, Toms Seisums toms.seis...@gmail.com wrote: [object Object] Look at Gmail failing flat on its face... lol Aside from that, can you perhaps try this patch: --- systemd-user-sessions.service 2013-10-02 15:37:14.181330287 -0700 +++ systemd-user-sessions.service 2013-10-04 11:53:37.02867 -0700 @@ -8,7 +8,7 @@ [Unit] Description=Permit User Sessions Documentation=man:systemd-user-sessions.service(8) -After=remote-fs.target +After=remote-fs.target dbus.service [Service] Type=oneshot some colleagues of mine identified that tasks in the user session that attempt to contact the system bus during shutdown may hang doing so. We can prevent this hang by making user sessions shut down entirely first before dbus is destroyed. It may or may not help. You can also insert After=dbus.service in to user@.service, but I feel this is a better spot. This sounds reasonable (until kdbus is here ;) ). However, should we perhaps take it one step further and order dbus.service Before=basic.target to also cover stuff outside of user sessions that may fall in its face when dbus goes away. Cheers, Tom -- Toms Seisums - (+371) 26431391 May the force be with you, always! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make fsck fix mode a kernel command line option
On Tue, Sep 10, 2013 at 04:55:19PM +0100, Colin Guthrie wrote: 'Twas brillig, and Tom Gundersen at 10/09/13 13:45 did gyre and gimble: On Tue, Sep 10, 2013 at 2:31 PM, Jan Engelhardt jeng...@inai.de wrote: On Tuesday 2013-09-10 13:52, Dave Reisner wrote: the FUSE program knows nothing about the systemd-specific nofail or x-*. We have nofail since 2007 in mount(8) (by patch from Suse:-), since 2009 in fsck(8) and since 2010 in swapon(8). Note that mount(8) does not strip nofail when call mount.type helpers. This should only be a problem if you directly use the FUSE mount helper. If you instead invoke mount with -t fuse.$fusetype, then this isn't an issue. mount(8) *does* understand these options and nicely strips them out before invoking the specific mount helper for you. If it were so that mount stripped them, I would not be reporting it, would I. Or maybe that is a feature of a future util-linux? # grep /mnt /etc/fstab /srv/www /mnt fuse.bindfs auto,nofail,group=company,perms=g+rw,create-for-group=www,create-with-perms=g+r:go-w 0 0 # mount /mnt fuse: unknown option `nofail' # rpm -q util-linux util-linux-2.21.2-10.2.1.x86_64 hmm... we have 2.24-rc1 now ;-) Hm, I thought that feature was part of 2.21... or perhaps your distro is still not using the libmount based mount? BTW, v2.24 is probably last release with old deprecated non-libmount based mount(8). I suspect this issue (libmount based mount) as this is what hit us a while back (I think our problem there was not using libmount in nfs-utils rather than mount itself, but my memory is fuzzy and I could be getting this wrong) It's really really bad idea to use old deprecated mount(8) on system with systemd. The old mount code is completely frozen in last years, no new features at all... Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
I'm not, it's started automatically. Might be an issue in Arch Linux. On 7 October 2013 20:33, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Mon, Oct 7, 2013 at 1:27 AM, Toms Seisums toms.seis...@gmail.com wrote: I got two systems having the exact same problem with similar symptoms. Both systems are upgraded to latest Arch Linux, and just recieved Linux Kernel 3.11.4 upgrades also. One is running on Linode, one is a local machine. Apparently, the fix provided by Auke does not resolve the problem. Tom Gundersens' one, though, does it. Two problems still remain, though: 1. The dbus notice message upon logging in (Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory). Why are you starting a session dbus for user root? Auke -- Toms Seisums - (+371) 26431391 May the force be with you, always! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
On Mon, Oct 07, 2013 at 10:03:22PM +0300, Toms Seisums wrote: On 7 October 2013 20:33, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Mon, Oct 7, 2013 at 1:27 AM, Toms Seisums toms.seis...@gmail.com wrote: I got two systems having the exact same problem with similar symptoms. Both systems are upgraded to latest Arch Linux, and just recieved Linux Kernel 3.11.4 upgrades also. One is running on Linode, one is a local machine. Apparently, the fix provided by Auke does not resolve the problem. Tom Gundersens' one, though, does it. Two problems still remain, though: 1. The dbus notice message upon logging in (Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory). Why are you starting a session dbus for user root? I'm not, it's started automatically. Might be an issue in Arch Linux. I think that we (as in upstream) start user@0.service whenever a root session is opened by cron or whatever. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
On Mon, Oct 7, 2013 at 12:08 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Oct 07, 2013 at 10:03:22PM +0300, Toms Seisums wrote: On 7 October 2013 20:33, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Mon, Oct 7, 2013 at 1:27 AM, Toms Seisums toms.seis...@gmail.com wrote: I got two systems having the exact same problem with similar symptoms. Both systems are upgraded to latest Arch Linux, and just recieved Linux Kernel 3.11.4 upgrades also. One is running on Linode, one is a local machine. Apparently, the fix provided by Auke does not resolve the problem. Tom Gundersens' one, though, does it. Two problems still remain, though: 1. The dbus notice message upon logging in (Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory). Why are you starting a session dbus for user root? I'm not, it's started automatically. Might be an issue in Arch Linux. I think that we (as in upstream) start user@0.service whenever a root session is opened by cron or whatever. ahh yes, I see that here now too. So, the reason that dbus.socket/dbus.service isn't setup or anything is that there is no properly setup default.target that requires or sets up dbus.socket for user sessions. Doing a `ln -sf /usr/lib/systemd/user/dbus.socket /etc/systemd/user/default.target.wants/dbus.socket` (quick hack) or something like that maybe helps, but you're running into the basic problem that there's just not enough there for systemd --user to do anything useful (no default target defined, no dependencies installed to sane defaults, etc.). Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Thu, Sep 12, 2013 at 10:13 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
On Thu, Sep 12, 2013 at 10:23 AM, Kay Sievers k...@vrfy.org wrote:
On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena
elena.reshet...@intel.com wrote:
For example, I can set a couple of smack-related xattrs in one go like
XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*.
Doesn't make sense from smack point of view (only smack64 is really
meaningful
on device nodes), but proves that functionality works.
right, but we could be setting other non-SMACK xattrs now all in one
go - for example, SELINUX ones (security.selinux).
Yeah, *looks* powerful, but also scary. :)
Udev now supports:
SECLABEL{smack}=name
http://cgit.freedesktop.org/systemd/systemd/commit/?id=c26547d612733371494330e26c7d3604a5dba3d9
Please check if that works for you.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
-Original Message-
From: Kay Sievers [mailto:k...@vrfy.org]
Sent: Monday, October 07, 2013 5:34 PM
To: Kok, Auke-jan H
Cc: Reshetova, Elena; Schaufler, Casey; systemd-
de...@lists.freedesktop.org; walyong@samsung.com; Ware, Ryan R
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev
On Thu, Sep 12, 2013 at 10:13 PM, Kok, Auke-jan H auke-
jan.h@intel.com wrote:
On Thu, Sep 12, 2013 at 10:23 AM, Kay Sievers k...@vrfy.org wrote:
On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena
elena.reshet...@intel.com wrote:
For example, I can set a couple of smack-related xattrs in one go
like XATTR{security.SMACK64}=*,
XATTR{security.SMACK64EXEC}=*.
Doesn't make sense from smack point of view (only smack64 is really
meaningful on device nodes), but proves that functionality works.
right, but we could be setting other non-SMACK xattrs now all in one
go - for example, SELINUX ones (security.selinux).
Yeah, *looks* powerful, but also scary. :)
Udev now supports:
SECLABEL{smack}=name
http://cgit.freedesktop.org/systemd/systemd/commit/?id=c26547d6127333
71494330e26c7d3604a5dba3d9
Please check if that works for you.
It's OK for devices. It won't work for files in general, as Smack
uses multiple attributes in certain cases. It won't work for any
future LSM that uses multiple SECLABELS on a device. Yes, I have
been requested to support multiple Smack labels on a file in
the past. There are security semantics that could make sense.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
В Mon, 7 Oct 2013 12:58:16 -0700 Kok, Auke-jan H auke-jan.h@intel.com пишет: Doing a `ln -sf /usr/lib/systemd/user/dbus.socket /etc/systemd/user/default.target.wants/dbus.socket` (quick hack) or something like that maybe helps, but you're running into the basic problem that there's just not enough there for systemd --user to do anything useful (no default target defined, no dependencies installed to sane defaults, etc.). If there nothing to run as user session, why systemd starts user session? You probably misunderstand the problem. Stock systemd will start user@0.service when session for root opens (and I assume user@$UID.service for each other user). This service sometimes does not stop on shutdown causing timeout. If this service is not needed, it should not be started, right? So it is not we who are running in basic problem - it is systemd which is running into basic problem :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Oct 8, 2013 at 2:54 AM, Schaufler, Casey casey.schauf...@intel.com wrote: http://cgit.freedesktop.org/systemd/systemd/commit/?id=c26547d6127333 71494330e26c7d3604a5dba3d9 Please check if that works for you. It's OK for devices. It won't work for files in general, as Smack uses multiple attributes in certain cases. Right, the udev directive applies to kernel device nodes only, it can't be used for any plain file. It won't work for any future LSM that uses multiple SECLABELS on a device. The code supports lists, but there will be explicit code in udev needed for any future LSM anyway, so this sounds fine, I guess. Yes, I have been requested to support multiple Smack labels on a file in the past. There are security semantics that could make sense. Sounds fine. We can catch up whenever needed. For now the udev directive matches the model we do for sockets, where the actual xattr is hidden; that's why we wanted it for udev in a similar fashion: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/socket.c#n799 Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
