Re: [systemd-devel] systemd-inhibit fails when run from a service file

2020-04-03 Thread Amish 

On 13/01/20 3:03 pm, Lennart Poettering wrote:

On Di, 26.11.19 13:55, Amish (anon.am...@gmail.com) wrote:


If I change code to not call systemd-inhibit:

$ cat /home/foo/downloads/dnld.sh
#!/bin/bash
/home/foo/downloads/dnld.pl

Then service file runs fine.

# systemctl start dnld.service; sleep 30
# journalctl -u dnld.service
Nov 26 13:50:17 foo systemd[1]: Started Download files.
Nov 26 13:50:37 foo systemd[1]: dnld.service: Succeeded.

So how do I allow systemd-inhibit call when a script is called via systemd
instead of directly?

Is this systemd bug or am I missing something in dnld.service file?

You need to allow this in PolicyKit. if you request an inhibitor from
a login shell you get policykit privs because of the default
policy. If you do this from a non-logged in user you won't, and need
to adjust the policy.

Lennart


I tried changing some PolicyKit settings but I was not successful.

However, I would admit that I did not understand the settings much either.

But how about having this as a feature for systemd.service.

Something like:

[Service]
Inhibit=shutdown,sleep,idle,...
InhibitMode=block|delay
ExecStart=...

So before running any command, systemd will inhibit accordingly. (can be 
useful even when run with User=foo set)


Any critical service which does not expect shutdown, reboot etc. can use 
this feature to block / delay the same while it is running.


I can file RFE if you want.

Thanks and regards,

Amish.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

2020-04-03 Thread Dimitri John Ledkov 
On Wed, 26 Feb 2020 at 09:59, Andreas Kempe  wrote:
>
> Hello everyone,
>
> I'm working in a project with an embedded Linux system based on
> Openembedded using Systemd version 241 as our init process. We're
> using a read-only /etc. To facilitate development, we want to use a
> writeable overlay on /etc, but we ran into an issue.
>
> When we start, Systemd detects that there is no machine-id file
> present in /etc so it generates and mounts a /etc/machine-id. When our
> mount unit then applies the overlay on /etc, it hides the mounted
> file. Journald later fails to start because /etc/machine-id isn't
> visible through the overlay.
>

I would expect the /etc/machine-id to exist, and be an empty file on
the RO underlay, then systemd should setup machine-id in /run, and
then after the overlay of /etc is setup to use and is RW, fire the
systemd-machine-id-commit.service unit which will transfer the
machine-id from /run into the RW /etc overlay, after that everything
else should operate "normal".

We do this in Ubuntu live installer images, which use overlayfs across
all of / on top of read-only squashfs rootfs.


> At this point we're considering a number of workarounds, but I thought
> it worthwhile asking the experts before we go patching Systemd or
> similar.

I think didrocks or pitti introduced above for all the cases we had in
ubuntu where we have RO rootfs with a writable overlay which "appears"
later.

No idea if above is suitable for you at all, and/or need tweaking.
I.e. self-transfer machine-id from /run to /etc with like adding
wants=/before= systemd-machine-id-commit.service or some such?

-- 
Regards,

Dimitri.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] OS shutting down after starting systemd-udevd.service through valgrind

2020-04-03 Thread Amit anand 
Hi,
I am trying to run systemd-udevd.service through valgrind for debugging
some memory corruption issue.

OS info :  64 bit Ubuntu OS. This is run as
guest vm.
RAM memory /swap size : 4GB RAM and 3 GB SWAP space.
systemd version   : systemd v237.

The command uname -a gives below result.
Linux [xxx] 4.14.147-yocto-standard #1 SMP PREEMPT Thu Jan 30 18:52:38 UTC
2020 x86_64 GNU/Linux
note : [xxx] is masked text.

Referred to link
*https://lists.freedesktop.org/archives/systemd-devel/2015-April/030086.html
*
.
Followed below steps to run systemd-udev.service through valgrind.

*step 1* :
On terminal, command "systemctl edit --full systemd-udev.service"

Prefixed it's ExecStart= parameter with an invocation of valgrind as below,
ExecStart=/usr/bin/valgrind --tool=memcheck /lib/systemd/systemd-udevd

*Step 2* :
On terminal, command "systemctl daemon-reload"

Step 3 :
On terminal, command "systemctl restart systemd-udevd"

Step 4 :
On terminal, command ps command gave below result for udevd.
[[0;1;32m●[[0m systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/etc/systemd/system/systemd-udevd.service; enabled;
vendor preset: enabled)
   Active: [[0;1;32mactive (running)[[0m since Fri 2020-04-03 14:40:41 UTC;
9s ago
 Docs: man:systemd-udevd.service(8)
   man:udev(7)
 Main PID: 13179 (memcheck-amd64-)
   Status: "Processing with 16 children at max"
   Memory: 42.6M
   CGroup: /system.slice/systemd-udevd.service
   └─13179 /usr/bin/valgrind --tool=memcheck
/lib/systemd/systemd-udevd


Step 5 : Could see few lines of valgrind output with "systemctl status
systemd-udev.service" command
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==by 0x4012BD1: ??? (in
/lib/ld-2.27.so)
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==by 0x5BFCC8B:
_dl_catch_exception (in /lib/libc-2.27.so)
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==by 0x4012789: ??? (in
/lib/ld-2.27.so)
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==by 0x5BFC2DC: ??? (in
/lib/libc-2.27.so)
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==by 0x5BFCC8B:
_dl_catch_exception (in /lib/libc-2.27.so)
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==by 0x5BFCCFE:
_dl_catch_error (in /lib/libc-2.27.so)
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==by 0x5BFC3A6: ??? (in
/lib/libc-2.27.so)
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==by 0x5BFC436:
__libc_dlopen_mode (in /lib/libc-2.27.so)
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==  Address 0x650b1c0 is 16
bytes after a block of size 32 in arena "client"
Apr 03 14:40:41 [xxx] valgrind[13179]: ==13179==

Note : [xxx] is masked text.

However, guest vm (Ubuntu OS) shut down within 2 minutes of restarting
systemd-udevd service.
Attempt to reboot the guest vm ( Ubuntu OS) failed.

Can you please guide/suggest how to prevent the Ubuntu OS from shutting
down after restarting systemd-udevd.service with valgrind.

Thanks,
Amit
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0

2020-04-03 Thread Pekka Paalanen 
On Thu, 02 Apr 2020 22:59:25 -0400
nerdopolis  wrote:

> On Tuesday, March 31, 2020 8:59:30 AM EDT Lennart Poettering wrote:
> > On Di, 28.01.20 22:48, nerdopolis (bluescreen_aven...@verizon.net) wrote:
> >   
> > > Hi
> > >
> > > Sorry if this is the wrong place for this. I can't seem to find a 
> > > system-user
> > > mailing list for this purpose on freedesktop.
> > >
> > > So I am curious about what CanMultiSession=no means, as I am able to 
> > > start a
> > > Weston session on a secondary seat (eg seat1 if I set up the hardware 
> > > with udev
> > > or seat-pci-pci-_xx_xx_x if I use pci-bridge-seat devices on QEMU.
> > >
> > > These seats, since they don't have TTYs I guess say CanMultiSession=no 
> > > which is
> > > my understanding, however, I can start a second instance of Weston, and 
> > > switch
> > > in between them fine, and Weston seems to respond to the sessions 
> > > switching, so
> > > I am not quite sure what is missing? Is it something else related to 
> > > security?
> > > Or the kernel?
> > >
> > > Because as far as I can tell, I can start multiple sessions on these 
> > > seats.  
> > 
> > Hmm, so it currently just lets you know if the seat has VTs (which
> > only seat0 has effectively, if the VT subsys is enabled in the
> > kernel).
> > 
> > In the old days we only supported session switching on seat0, since it
> > was based exclusively on VTs. Later on David Hermann added support for
> > session switching without VTs, at which point the boolean was wired to
> > mean "has VTs". Maybe that was a mistake, dunno, and it should just
> > have returned true for all seats at that point...
> > 
> > Lennart
> > 
> > --
> > Lennart Poettering, Berlin
> >   
> Thanks. I was wondering if there was some security thing that depended on TTYs
> for the two Display Servers running on the same seat to truly be secure or 
> not.
> (like reading /dev/input/* )
> 
> If you don't need TTYs to prevent the non-seat0 session from reading input 
> from
> the other non-seat0 session, the same as on seat0, then yeah, as I've been 
> able
> to run and switch between two sessions on non-seat0 since I first tried it in 
> 2017...
> 
> 
> 
> One thing I did notice though is that (as far as leaking input)
> 
> - if run Display Servers on the secondary seat (one, or more than one)
> - On seat0, I chvt to a text-mode TTY
> - Continuing to use the secondary seat, all keyboard and mouse (gpm) input
>   gets sent to the TTY (and the actual display server)
> - Switching back to a TTY with a display server, and the seats behave separate
>   again
> 
> 
> My (maybe bad) guess is that it would need to be addressed in the kernel 
> though
> And the CanMultiSession attribute on non-seat0 doesn't matter when the 
> problem 
> is all input from all devices gets sent to seat0 when seat0 is in a text mode
> TTY
> 
> ..and even if you have some kmscon like thing installed, there could still be 
> text mode TTYs

Hi,

that is both an excellent and horrifying observation. And it makes
perfect sense to me why that happens, just like you think: seat
assignments happen in userspace as udev properties. Someone would have
to explicitly tell the kernel about it too to fix this, e.g. remove
non-seat0 devices from the VT machinery.

I wonder if such kernel interface even exists?

The reason why display servers do not cross their input streams like
that is that display servers do not use the VT for input. But VT gets
its input assigned directly inside the kernel.


Thanks,
pq


pgpmubB9uXJ6V.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel