Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241

[Mike Gilbert]

On Sat, May 11, 2019 at 1:19 PM tedheadster  wrote:
>
> On Sat, May 11, 2019 at 12:30 PM Florian Weimer  wrote:
> > Can you capture register contents at the point of the crash?
> >
> > Does this reproduce in a chroot?  Maybe you can trace the whole thing
> > with a debugger.  Does the crash reproduce if you single-step through
> > the whole function?
>
> Florian,
>   I figured out the problem, I just haven't written code to fix it.
> The documentation I can find is silent about what is returned in %ecx
> and %ebx when calling cpuid function 0x0001 on IDT Winchip-C6 and
> Winchip2.
>
> I think %ecx  should properly contain 0x, but it instead puts
> the 'auls' characters from cpuid function 0x (vendor string
> 'CentaurHauls') in %ecx:

Just a guess: I wonder if that 'auls' value is left over from the
previous CPUID result. If that's the case, a simple solution might be
to zero-out ebx, ecx, and edx in __cpuid().
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] ask-password: prevent buffer overrow when reading from keyring

[systemd github import bot]

Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] ask-password: prevent buffer overrow when reading from keyring

[Thadeu Lima de Souza Cascardo]

When we read from keyring, a temporary buffer is allocated in order to
determine the size needed for the entire data. However, when zeroing that area,
we use the data size returned by the read instead of the lesser size allocate
for the buffer.

That will cause memory corruption that causes systemd-cryptsetup to crash
either when a single large password is used or when multiple passwords have
already been pushed to the keyring.

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 src/shared/ask-password-api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/shared/ask-password-api.c b/src/shared/ask-password-api.c
index ab0c34692f1c..6c0a36990291 100644
--- a/src/shared/ask-password-api.c
+++ b/src/shared/ask-password-api.c
@@ -80,7 +80,7 @@ static int retrieve_key(key_serial_t serial, char ***ret) {
 if (n < m)
 break;
 
-explicit_bzero_safe(p, n);
+explicit_bzero_safe(p, m);
 
 if (m > LONG_MAX / 2) /* overflow check */
 return -ENOMEM;
-- 
2.20.1

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

Re: [systemd-devel] logind-dbus-session question

[Damian Ivanov]

> > The methods in question are TakeControl/ReleaseControl for grabbing
> > the input via busctl.
> > ReleaseControl => You are not in control of this session
> > TakeControl b true => Access denied
>
> if "force" is true you have to be root. Pass false and have the EUID
> of the session owner if you want unprivileged access.
>



Thank you Lennart, this answers the questions. I would not have figured to
> pass false.
>

Have a great day.


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

[systemd-devel] Password agent for user services

[Michal Koutný]

Hello,
I was pondering a user service that would ask for password via the
password agent infrastructure (as there is
systemd-gnome-ask-password-agent it could be quite integrated with the
desktop environment) as an alternative to saving it in (Gnome) keyring.

Naïve experiment with

> [Service]
> ExecStart=/usr/bin/systemd-ask-password "What is your pwd?"

lead to

> May 13 19:49:56 host systemd-ask-password[28844]: Failed to query password: 
> Permission denied

Then I read about the password agent API [1] and realized that poor
agent cannot create the notification file in the watched directory. I
also noticed the auxiliary agent is not spawned for user services [2].

I'm not that familiar with policy-kit, however, IIUC, it is possible to
ask unprivileged systemd-gnome-ask-password-agent to provide a password
for system service. Is that correct?
What would then prohibit making /run/systemd/ask-password world writable
to allow unprivileged users to ask for a password?

(I understand the interface is so crude so that it works at early boot
stages w/out DBus. For the user requests it would perhaps make sense to
make have a parallel DBus API.)

Or is there an alternative approach to query interactively passwords for
user services (e.g. already existing user service that could queried via
DBus)?

Thanks,
Michal


[1] https://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/
[2] 
https://github.com/systemd/systemd/blob/a45ef5070d5875d70e39fc430e82eb26c221ded5/src/systemctl/systemctl.c#L238


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

Re: [systemd-devel] sd-bus dynamic property table

[Simon McVittie]

On Mon, 13 May 2019 at 08:25:03 -0700, Stephen Hemminger wrote:
> The next step is to add ethtool statistics. Each type of network device will 
> have
> different set of named properties.

This is really a D-Bus API design query, not a systemd query.

The standard D-Bus Properties interface is not designed for use
with arbitrary/dynamic named attributes. It's intended to be a D-Bus
equivalent of GObject properties or Qt properties, which are set up
in the object's source code: their values might vary at runtime, but
the list of properties that exists in a class or interface is part of
the API of that class or interface and does not change[1]. Similarly,
D-Bus properties exist in an interface alongside methods and signals,
and an interface either has a Foo property or it doesn't: if it does,
then every object that implements the interface also has a Foo property.

If you need named attributes that vary between objects, I'd suggest
representing them as either a single large property with an a{sv}
as its value, or a D-Bus interface that structurally resembles
Properties but is not Properties (for instance you could call it
com.example.NetworkStatistics, replacing com.example with your reversed
domain name, and have a GetStatistics() -> a{sv} method and optionally
a StatisticsChanged signal).

The org.freedesktop.DBus.Debug.Stats interface in dbus-daemon (it's
compile-time conditional, so your dbus-daemon might not have it)
provides an example of an interface that puts arbitrary attributes
in the result of a method call.

smcv

[1] except for maybe backward-compatible feature enhancements where
newer versions introduce more properties
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

[František Šumšal]

On 5/13/19 8:20 AM, Ulrich Windl wrote:

>> "systemd‑analyze verify" exists. Since a long long time.
> 
> Not really: You can't verify a unit file while it's not "installed". Comare it
> to validating an XML file, for example.
> 

That's actually not true. The argument for `systemd-analyze verify` is a file 
name,
so you verify an arbitrary file for correctness:

$ cat > test.service << EOF
> [Unit]
> Description=test unit
> 
> [Service]
> ExecStrt=/bin/true
> EOF
$ systemd-analyze verify test.service 
File /usr/lib/systemd/system/systemd-udevd.service:26 configures an IP firewall 
(IPAddressDeny=any), but the local system does not support BPF/cgroup based 
firewalling.
Proceeding WITHOUT firewalling in effect! (This warning is only shown for the 
first loaded unit using IP firewalling.)
/tmp/./test.service:4: Unknown lvalue 'ExecStrt' in section 'Service'
test.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Unit test.service has a bad unit file setting.
$ systemctl status test.service
Unit test.service could not be found.


-- 
GPG key ID: 0xFB738CE27B634E4B



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

[systemd-devel] sd-bus dynamic property table

[Stephen Hemminger]

I have a simple application that does provides property table for network
devices (maybe it would be useful for a more complete example somewhere).
The app is more to show how to use sdbus, not to replace network manager.

The next step is to add ethtool statistics. Each type of network device will 
have
different set of named properties. How could this be implemented?
So far, the only idea would be to dynamically build a vtable then
register it?


# busctl tree  org.networkplumber.net1
└─/org
  └─/org/networkplumber
└─/org/networkplumber/net1
  └─/org/networkplumber/net1/interface
├─/org/networkplumber/net1/interface/eno1
├─/org/networkplumber/net1/interface/eno2
├─/org/networkplumber/net1/interface/ens11
└─/org/networkplumber/net1/interface/lo

# busctl introspect org.networkplumber.net1 
/org/networkplumber/net1/interface/eno1
NAMETYPE  SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer   interface - --
.GetMachineId   method- s-
.Ping   method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv   --
.PropertiesChanged  signalsa{sv}as  --
org.networkplumber.net1.Interface   interface - --
.carrierproperty  q 1-
.ifindexproperty  q 2-
.iflink property  q 2-
.mtuproperty  q 1500 -


Want to be able to add these:
# ethtool -S eno1 | grep -v ' 0$'
NIC statistics:
 rx_packets: 84980
 tx_packets: 32068
 rx_bytes: 107413644
 tx_bytes: 9299204
 rx_broadcast: 219
 tx_broadcast: 84
 rx_multicast: 152
 tx_multicast: 157
 multicast: 152
 tx_tcp_seg_good: 1561
 rx_long_byte_count: 107413644
 tx_queue_0_packets: 6888
 tx_queue_0_bytes: 3127349
 tx_queue_1_packets: 6307
 tx_queue_1_bytes: 3623152
 tx_queue_2_packets: 12569
 tx_queue_2_bytes: 1239345
 tx_queue_3_packets: 6304
 tx_queue_3_bytes: 1163512
 rx_queue_0_packets: 17936
 rx_queue_0_bytes: 21464312
 rx_queue_1_packets: 20651
 rx_queue_1_bytes: 27029893
 rx_queue_2_packets: 12642
 rx_queue_2_bytes: 13132543
 rx_queue_3_packets: 33751
 rx_queue_3_bytes: 45446976

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

Re: [systemd-devel] Antw: Re: rdrand generated with march=winchip-c6 in systemd-241

[Reindl Harald]

Am 13.05.19 um 09:10 schrieb Ulrich Windl:
 tedheadster  schrieb am 11.05.2019 um 19:19 in 
 Nachricht
> :
>> On Sat, May 11, 2019 at 12:30 PM Florian Weimer  wrote:
>>> Can you capture register contents at the point of the crash?
>>>
>>> Does this reproduce in a chroot?  Maybe you can trace the whole thing
>>> with a debugger.  Does the crash reproduce if you single-step through
>>> the whole function?
>>
>> Florian,
>>   I figured out the problem, I just haven't written code to fix it.
>> The documentation I can find is silent about what is returned in %ecx
>> and %ebx when calling cpuid function 0x0001 on IDT Winchip-C6 and
>> Winchip2.
>>
>> I think %ecx  should properly contain 0x, but it instead puts
>> the 'auls' characters from cpuid function 0x (vendor string
>> 'CentaurHauls') in %ecx:
>>
>> %ebx = 0x746e6543 = "Cent"
>> %edx = 0x48727561 = "aurH"
>> %ecx = 0x736c7561 = "auls"
>>
>> This sets bit 30 (0x736c7561) 'on', the 'supports rdrand' bit.
>>
>> So we have to code around the vendor and chip model in this case.
>> Jeffrey Walton gave some coding examples I might consider
>> (https://github.com/weidai11/cryptopp/blob/master/cpu.cpp#L380).
> 
> 
> I didn't see the start of this thread, but is it another attempt to 
> re-implement /proc/cpuinfo's flags?

can you please stop all that trolling?
cpuid has *nothing* to do with /proc/cpuinfo

https://en.wikipedia.org/wiki/CPUID
The CPUID instruction (identified by a CPUID opcode) is a processor
supplementary instruction

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

Re: [systemd-devel] Antw: Re: Antw: Re: rdrand generated with march=winchip-c6 in systemd-241

[Reindl Harald]

Am 13.05.19 um 09:18 schrieb Ulrich Windl:
>>> I didn't see the start of this thread, but is it another attempt to 
>> re-implement /proc/cpuinfo's flags?
>>
>> can you please stop all that trolling?
> 
> Actually the number of unfriendly words from your side beat mine by an order 
> of magnitude...

it's not about friendly, it's about provocations with little knowledge

>> cpuid has *nothing* to do with /proc/cpuinfo
>>
>> https://en.wikipedia.org/wiki/CPUID 
>> The CPUID instruction (identified by a CPUID opcode) is a processor
>> supplementary instruction
> 
> Isn't it about to check a CPU's feature depending on the CPU model?
yes, but you confuse cause and effect, guess from where the kernel
output is coming and what you see in /proc/cpuid is just a tiny part of
it, just look at the output of the "cpuid" command and compare it with
/proc/cpuinfo

nobody in binary software digs around in /proc when there are *OPCODES*
/proc/cpuid is for you shell scripts

why didn't you just read and trying to understand
https://en.wikipedia.org/wiki/CPUID





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

Re: [systemd-devel] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

[Reindl Harald]

Am 13.05.19 um 08:20 schrieb Ulrich Windl:
>> Note that "/var/run" is a legacy alias for "/run". It's highly
>> recommended not to use the former anymore.
> 
> It it because you don't like sub-directories, or is it to save four bytes?
> ;-)


stop it - if you would have read IT news (golem/heise) the last 7 years
or so you would know about /run and why it is a top-directory

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

/run

Run-time variable data: Information about the running system since last
boot, e.g., currently logged-in users and running daemons. Files under
this directory must be either removed or truncated at the beginning of
the boot process; but this is not necessary on systems that provide this
directory as a temporary filesystem (tmpfs).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241

[tedheadster]

On Mon, May 13, 2019 at 3:10 AM Ulrich Windl
 wrote:
>
> >>> tedheadster  schrieb am 11.05.2019 um 19:19 in 
> >>> Nachricht
> :
> > On Sat, May 11, 2019 at 12:30 PM Florian Weimer  wrote:
> >> Can you capture register contents at the point of the crash?
> >>
> >> Does this reproduce in a chroot?  Maybe you can trace the whole thing
> >> with a debugger.  Does the crash reproduce if you single-step through
> >> the whole function?
> >
> > Florian,
> >   I figured out the problem, I just haven't written code to fix it.
> > The documentation I can find is silent about what is returned in %ecx
> > and %ebx when calling cpuid function 0x0001 on IDT Winchip-C6 and
> > Winchip2.
> >
> > I think %ecx  should properly contain 0x, but it instead puts
> > the 'auls' characters from cpuid function 0x (vendor string
> > 'CentaurHauls') in %ecx:
> >
> > %ebx = 0x746e6543 = "Cent"
> > %edx = 0x48727561 = "aurH"
> > %ecx = 0x736c7561 = "auls"
> >
> > This sets bit 30 (0x736c7561) 'on', the 'supports rdrand' bit.
> >
> > So we have to code around the vendor and chip model in this case.
> > Jeffrey Walton gave some coding examples I might consider
> > (https://github.com/weidai11/cryptopp/blob/master/cpu.cpp#L380).
>
>
> I didn't see the start of this thread, but is it another attempt to 
> re-implement /proc/cpuinfo's flags?
>

No, I don't propose we re-implement /proc/cpuinfo's flags.

We need code around the IDT Winchip2 not reporting correct information
in %ecx when given a cpuid() request with parameter 0x0001.

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

Re: [systemd-devel] systemd-nspawn and cgroup hybrid mode

[Antoine Pietri]

On Mon, May 13, 2019 at 10:42 AM Lennart Poettering
 wrote:
> you can use it to lock up the machine, hence we generally don't do it.

Thanks, got it. For my usecase though, security isn't much of a
concern and I don't necessarily have the time/bandwidth to migrate the
software to cgroupsv2 upstream right now. Is there an option "this
will void your warranty" that I can enable to force delegation in the
hybrid setup? :-)

Thanks,

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

Re: [systemd-devel] sd-bus: Enabling free-standing, bus-independent plain messages

[Simon McVittie]

On Mon, 13 May 2019 at 10:38:38 +0200, Lennart Poettering wrote:
> On So, 12.05.19 13:06, Stanislav Angelovič (angelovi...@gmail.com) wrote:
> > Quick question: Would it be possible to extend sd-bus to also allow
> > creating messages without requiring a bus?
> 
> This used to be available but we dropped it, since the serialization
> depends on the bus feature set, i.e. wheter fd passing is available,
> and whether gvariant serialization is available.

I think it might make sense to have a way to serialize data to a D-Bus
1.0 message, and/or to a GVariant. I agree that it doesn't make sense
to serialize to an unspecified D-Bus-adjacent binary format, unless you
already know which bus you are talking to, in which case you should use
the most natural format for that bus.

> What's the usecase for using bus message as general marshalling
> storage anyway? Can you elaborate?

Various GLib-related projects like gvdb (used in dconf) and libostree
use GVariant as a stable on-disk encoding for strongly-typed data,
reusing GVariant's D-Bus-inspired type model, in the same sorts of
places that a different project might have used (for example) JSON,
XDR or Protocol Buffers.

Again, this is a reasonable thing to do with data known to be serialized
in GVariant format, or known to be serialized in D-Bus 1.0 format, but
not a reasonable thing to do with a binary format that might be GVariant
or D-Bus 1.0 or some future message encoding.

If what you want is a "variant" type, note that the recursive type
systems of both GVariant and D-Bus 1.0 require out-of-band information
to encode/decode. For both formats, you need to know the type signature
(e.g. "a{sv}") and the byte-order (big- or little-endian), and for
GVariant you additionally need to know the message length in bytes. On
D-Bus this information is already available in the message header, but
if you're using GVariant or D-Bus 1.0 as a standalone serialization you
will need to provide or reinvent a subset of the message header.

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

Re: [systemd-devel] systemd-nspawn and cgroup hybrid mode

[Lennart Poettering]

On So, 12.05.19 14:09, Antoine Pietri (antoine.piet...@gmail.com) wrote:

> Hi,
>
> I have a probably dumb question for which I couldn't find an answer in
> the docs. I'm trying to make a program that uses the cgroupv1 API run
> into a systemd-nspawn container. In the host, I know that I can just
> look at /proc/self/cgroup to see the path of my cgroup and write stuff
> there. The legacy cgroup tree is properly created on the host:
>
> $ systemd-run --pty find /sys/fs/cgroup/ | grep 'run-u[0-9]' | grep
> group/memory/
> /sys/fs/cgroup/memory/system.slice/run-u4161.service/cgroup.procs
> /sys/fs/cgroup/memory/system.slice/run-u4161.service/memory.use_hierarchy
> /sys/fs/cgroup/memory/system.slice/run-u4161.service/memory.kmem.tcp.usage_in_bytes
> /sys/fs/cgroup/memory/system.slice/run-u4161.service/memory.soft_limit_in_bytes
> [...]
>
> But when I'm in the container, it doesn't work anymore. Running the
> same command returns no results. Now, this is most certainly due to
> the fact that in the container, /sys/fs/cgroup is mounted in read-only
> so systemd can't create anything in /sys/fs/cgroup/memory... but then,
> what is the proper way to write into the legacy cgroups? I also tried
> to turn on Delegate=true to see if it would change something, but it
> doesn't.

Delegation of the various controllers to less privileged environments
(i.e. from host to container) is not safe on cgroupsv1, you can use it
to lock up the machine, hence we generally don't do it.

Delegation of the various controllers to less privileged environments
is safe on cgroupsv2, and there we do it. That's why you'll find
controllers such as "memory" delegated to nspawn containers and
systemd --user by default on such systems.

The "hybrid" setup is in most ways like cgroupsv1, i.e. all
controllers are still access the cgroupsv1 way, and hence delegation
is not done there either.

It's a major reason why people really should switch to cgroupsv2 now.

Lennart

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

Re: [systemd-devel] sd-bus: Enabling free-standing, bus-independent plain messages

[Lennart Poettering]

On So, 12.05.19 13:06, Stanislav Angelovič (angelovi...@gmail.com) wrote:

> Hi (Lennart :)
>
> Quick question: Would it be possible to extend sd-bus to also allow
> creating messages without requiring a bus?

This used to be available but we dropped it, since the serialization
depends on the bus feature set, i.e. wheter fd passing is available,
and whether gvariant serialization is available. Some of that never
materialized IRL due to the demise of kdbus, but the semantics still
make sense: serialization depends on the feature set of the bus, and
hence each message should be associated with a connection.

> Let me explain: Currently, if we want to create any message in sd-bus, we
> need a valid bus pointer. That might make perfect sense for messages that
> come from or will eventually go to bus. But sd-bus also supports plain
> messages. Do we also need that hard msg->bus dependency for plain messages
> which we use only as a local, temporary storage of serialized data?
>
> Some years ago we had a little discussion about a few tweaks in sd-bus API
> to allow modelling the concept of Variant type in higher-level sd-bus
> bindings (
> https://lists.freedesktop.org/archives/systemd-devel/2016-November/037929.html).
> A Variant is essentially implemented as a class around plain sd-bus message
> which is only used a storage of the underlying type. To create a Variant
> instance, we simply call `sd_bus_message_new` factory with type
> _SD_BUS_MESSAGE_TYPE_INVALID. Nice and simple. But that factory requires
> real bus ptr. This leads to a more complicated, less efficient and
> not-that-nice solution that must take hold of some bus (if there is none it
> must create one), must cache the bus (so that it's not created and
> destroyed at every creation/deletion of Variant instance). Yes, we have
> `sd_bus_default_system`, but even with that there is some effort that has
> some pitfalls (e.g. we can't `std::move` a Variant to a different thread,
> because it might potentially outlive the current one). All that
> nomenclature is needed just to get a plain message to read/write
> data from.

So we could readd the ability to create a bus message with a NULL bus,
but I am a bit concerned that people then always pass NULL which might
ultimately result in constant remarshalling if the message is
eventually enqueued on a real bus. When you put together a message it
actually matters which bus connection you do that for...

> Even today, vast majority of these functions doesn't seem to need the bus.
> The exception are `sd_bus_message_seal` and `sd_bus_message_new` itself.
> We'd need to either modify `sd_bus_message_new` to allow taking in NULL bus
> ptr, or creating a new function for creating such plain local messages.
> We'd need to modify `sd_bus_message_seal` to simply consider the fact that
> m->bus can be NULL. And we'd probably need to add asserts for m->bus to
> functions which truly require real bus ptr presence. (We might even provide
> the option to link the message to a real bus later, and introduce new
> `sd_bus_message_set_bus` function, but I'm not sure whether that is good.)
>
> To summarize: sd-bus already offers API for creating plain message. To make
> it fully true, let's just not require the bus there. The proposed change
> would IMHO make  sd-bus message more flexible, and would make it easier,
> more intuitive and more robust to work with and model Variants around such
> free-standing, bus-independent sd-bus messages in higher-level languages.
>
> What do you think?

Note that message behaviour and so on depends in sometimes subtle and sometimes 
not
so subtle ways on the bus connection used, i.e. whether we are talking
to a real bus or not, and so on. I am not to keen of making this
completely independent I must admit...

What's the usecase for using bus message as general marshalling
storage anyway? Can you elaborate?

A compromise might be that we readd a concept of allowing
bus-independent messages to be generated again (i.e. pass NULL as bus
object when creating a bus message), with the most reduced feature set
possible, and at the same time refuse to enqueue such messages on any
bus, thus forcing people to use sd_bus_message_copy() to explicitly
remarshal for the bus, instead of doing implicitly so. if you want to
prep such a patch I think we should merge it.

Lennart

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

Re: [systemd-devel] logind-dbus-session question

[Lennart Poettering]

On Sa, 11.05.19 16:29, Damian Ivanov (damianator...@gmail.com) wrote:

> Hello folks.
>
> Thank you for being pioneers in the field!
>
> I am trying to get responses from the login1 system bus, but I get
> Access Denied messages.
> I am calling it as normal user (the user of the session - as root it
> works). SELinux is disabled.
>
> The methods in question are TakeControl/ReleaseControl for grabbing
> the input via busctl.
> ReleaseControl => You are not in control of this session
> TakeControl b true => Access denied

if "force" is true you have to be root. Pass false and have the EUID
of the session owner if you want unprivileged access.


> So another process is currently grabbing the input (for the
> console/VT I think).

The console/VT doesn't grab input from logind really. logind only
manages arbitration/grabbing for its own clients, i.e. only programs
talking to logind.

> Yet when you run weston it does grab the input by taking control, how
> does weston have the permission to kick the console controller out
> (weston is not run as root)? How can I check the pid of the process
> that owns the session control?

It shouldn't need that, unless you are running two Westons (or
Weston-like programs) on the same session.

Lennart

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

Re: [systemd-devel] systemctl list all possible (including unloaded) services

[Lennart Poettering]

On Fr, 10.05.19 13:27, Roger Pack (rogerdpa...@gmail.com) wrote:

> > Seems to work here. I have just one sysvinit script:
> > $ ls /etc/init.d/
> > functions  network  README
> > $ systemctl list-unit-files 'network*'
> > UNIT FILE STATE
> > network.service   generated
> > ...
> > $ systemctl cat network.service
> > # /run/systemd/generator.late/network.service
> > # Automatically generated by systemd-sysv-generator
> > ...
> > $ systemctl start network # autocompletes to network.service
> >
> > $ systemctl --version
> > systemd 241 (v241-7.gita2eaa1c.fc30)
>
> Interesting.  I tried the following on a Debian 8 box, where
> /etc/init.d/sysstat exists
>
> # systemctl --version
> systemd 215
> # systemctl enable sysstat
> Synchronizing state for sysstat.service with sysvinit using update-rc.d...
> Executing /usr/sbin/update-rc.d sysstat defaults
> Executing /usr/sbin/update-rc.d sysstat enable
> # systemctl list-unit-files | grep sysstat
> (empty, even if it's enabled)
> # systemctl
> However on a Debian 9 box:
> # systemctl --version
> systemd 232
> # systemctl list-unit-files | grep sysstat
> sysstat.servicegenerated
>
> It's always listed even if it's disabled.
>
> Unfortunately I can't easily test a CentOS box with a newer systemctl
> since its version of libmount seems stuck at "old" version 2.32.  But
> for now hoping it was just a bug fixed in later versions.  Also of
> note is that with older versions of systemctl, as expected, if it
> "attempted" to autostart an init.d but failed, it would still show up
> in the output of `systemctl list-units`, but never in the output of
> list-unit-files, which is what gave me the initial impression it
> wasn't available at all if it didn't autostart.
> Thanks all for the feedback and help!

In really old systemd versions "systemctl list-unit-files" only showed
native unit files. In newer versions we also display generated unit
files, to make them more discoverable.

Lennart

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

Re: [systemd-devel] interacting with logind to detect user idle time

[Lennart Poettering]

On Mi, 08.05.19 14:37, Germano Massullo (germano.massu...@gmail.com) wrote:

> Hi, I am doing some practice with writing software using GDBus API. I
> need it to implement on BOINC client, user(s) idle time detection by
> retrieving such info from logind.
> In order to retrieve user idle time I was thinking of using the
> property IdleSinceHint. What do you think about?

Yes, it tells you about the time logind thinks a session has been
idle. Note that it only works correctly on desktops that support it.

Lennart

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

Re: [systemd-devel] Antw: Re: Explain status "Loaded: not-found (Reason: No such file or directory)"

[Lennart Poettering]

On Mo, 13.05.19 08:08, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > Typically, when you see "not-found" as "Loaded" value, you'll also see
> > "No such file or directory" as "Reason" value, but there are some
> > other cases, since units are not always synthesized from unit files on
> > disk, but from other concepts too.
> >
>
> Thanks for the explanation; it's more clear now. However I'd prefer a message
> like "Loaded: iotwatch.target could not be found", so
> * name what is missing, and
> * use an "errno message" only for specific system calls (not to summarize
> several)

The name of the unit missing is shown in the same output a tiny bit
further up, we try to repeat ourselves too often. "systemctl status"
is supposed to compress a lot of information into little space.

Note that these "errno" error strings are generally how things are
done on UNIX. For example, if you use plain "rm" to remove a missing
file, or "cat" to cat it you get the same error strings:

$ rm 
rm: cannot remove '': No such file or directory
$ cat 
cat: : No such file or directory

UNIX admins typically recognize the "No such file or directory" phrase
and know what it means. I mean, UNIX is sometimes a bit cryptic, but
it is how it is...

Lennart

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

Re: [systemd-devel] Antw: Re: Antw: Re: rdrand generated with march=winchip-c6 in systemd-241

[Lennart Poettering]

On Mo, 13.05.19 09:18, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

Please guys, stop it.

> > cpuid has *nothing* to do with /proc/cpuinfo
> >
> > https://en.wikipedia.org/wiki/CPUID
> > The CPUID instruction (identified by a CPUID opcode) is a processor
> > supplementary instruction
>
> Isn't it about to check a CPU's feature depending on the CPU model?

Ulrich, please understand that __get_cpuid() (which the discussion
here is about) is a gcc and llvm/clang feature weare are just making
use of. It used by various Linux software, and apparently doesn't work
entirely correctly on all CPUs in some corner case. The discussion is
about fixing gcc accordingly, and making it work, so that systemd all
all other software can work correctly.

If you think that gcc/llvm are bad for "reimplementing /proc/cpuinfo"
then please bring that up with those communities, but please stop
these fruitless discussions here.

Thank you for understanding,

Lennart

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

Re: [systemd-devel] Antw: Re: Explain status "Loaded: not-found (Reason: No such file or directory)"

[Lennart Poettering]

On Mo, 13.05.19 07:48, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >> I guess it's not a file named "Reason" that's missing. Despite of my
> >> recommendation to create helpful error messages, can you explain what it
> > means?
> >> Even after an strace I could not find out what is missing.
> >>
> >
> > It means that unit definition file (iotwatch.target) was not found in
> > any directory where systemd looks for it.
>
> The confusing part is that something that cannot be found is "active" for 18
> minutes ;-)

If you start a unit, then remove its unit file it remains started but
the unit file cannot be found anymore. We try to make the best of it:
leave the service running as well as possible, but will tell you the
unit file is now absent.

Of course, it's not a good idea to remove a unit file while a service
is still running, but we cannot really stop you from doing so, this
being UNIX and all...

Lennart

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

Re: [systemd-devel] Antw: Re: Can I enable/disable a target?

[Lennart Poettering]

On Mo, 13.05.19 08:25, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >> Whenever I try to enable or disable a target (that exists), I get
> >> "Failed to execute operation: No such file or directory". What file
> >> or directory, please? Or what is the command trying to say?
> >
> > Well, "systemctl enable" could not find the target unit file in the
> > directories it searches for them. Where did you place the unit file?
>
> Meanwhile I know: My generator was using bash, and for more reliability I
> dared to add "set -u". As it turned out my version of Bash has a bug that
> causes false reports of unset variables with arrays, so the generator failed
> (the thread of handling exit codes of generators). As a consequence of that,
> the unit file wasn't created any more (which I hadn't realized at that time).
>
> But still combining the concepts "operation" and "No such file or directory"
> is odd: An operation is neither a file nor a directory.

On unix, this is typically how errors are shown. It's built into basic
ANSI C and POSIX concepts if you so will, as "perror()" will output
error messages like this: a short app message string followed by a
colon and a space character, followed by the system error string. The
system error string is one of the "errno" strings listed on the
errno(3) man page, i.e "No such file or directory" is ENOENT. The app
error string usually says what was attempted when the system error was
seen.

systemd matches these UNIX semantics closely: we output error messages
exactly the same way as everything else on UNIX: a brief string
explaining what was attempted, followed by a colon, followed by a
space, followed by the system error string.

I mean, sure we can always tweak error messages more, but we generally
start from how C and UNIX suggest these works, and then improve from
there.

I mean, we are used to being blamed for everything by everyone, but if
you want to criticise ANSI/POSIX "perror()" style error messages on
principle, then please direct this towards the ANSI C and POSIX
committees first.

Lennart

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

[systemd-devel] Antw: Re: Antw: Re: rdrand generated with march=winchip-c6 in systemd-241

[Ulrich Windl]

>>> Reindl Harald  schrieb am 13.05.2019 um 09:14 in
Nachricht :

> 
> Am 13.05.19 um 09:10 schrieb Ulrich Windl:
> tedheadster  schrieb am 11.05.2019 um 19:19 in 
> Nachricht
>> :
>>> On Sat, May 11, 2019 at 12:30 PM Florian Weimer  wrote:
 Can you capture register contents at the point of the crash?

 Does this reproduce in a chroot?  Maybe you can trace the whole thing
 with a debugger.  Does the crash reproduce if you single-step through
 the whole function?
>>>
>>> Florian,
>>>   I figured out the problem, I just haven't written code to fix it.
>>> The documentation I can find is silent about what is returned in %ecx
>>> and %ebx when calling cpuid function 0x0001 on IDT Winchip-C6 and
>>> Winchip2.
>>>
>>> I think %ecx  should properly contain 0x, but it instead puts
>>> the 'auls' characters from cpuid function 0x (vendor string
>>> 'CentaurHauls') in %ecx:
>>>
>>> %ebx = 0x746e6543 = "Cent"
>>> %edx = 0x48727561 = "aurH"
>>> %ecx = 0x736c7561 = "auls"
>>>
>>> This sets bit 30 (0x736c7561) 'on', the 'supports rdrand' bit.
>>>
>>> So we have to code around the vendor and chip model in this case.
>>> Jeffrey Walton gave some coding examples I might consider
>>> (https://github.com/weidai11/cryptopp/blob/master/cpu.cpp#L380).
>> 
>> 
>> I didn't see the start of this thread, but is it another attempt to 
> re-implement /proc/cpuinfo's flags?
> 
> can you please stop all that trolling?

Actually the number of unfriendly words from your side beat mine by an order of 
magnitude...

> cpuid has *nothing* to do with /proc/cpuinfo
> 
> https://en.wikipedia.org/wiki/CPUID 
> The CPUID instruction (identified by a CPUID opcode) is a processor
> supplementary instruction

Isn't it about to check a CPU's feature depending on the CPU model?

Regards,
Ulrich



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

[systemd-devel] Antw: Re: rdrand generated with march=winchip-c6 in systemd-241

[Ulrich Windl]

>>> tedheadster  schrieb am 11.05.2019 um 19:19 in 
>>> Nachricht
:
> On Sat, May 11, 2019 at 12:30 PM Florian Weimer  wrote:
>> Can you capture register contents at the point of the crash?
>>
>> Does this reproduce in a chroot?  Maybe you can trace the whole thing
>> with a debugger.  Does the crash reproduce if you single-step through
>> the whole function?
> 
> Florian,
>   I figured out the problem, I just haven't written code to fix it.
> The documentation I can find is silent about what is returned in %ecx
> and %ebx when calling cpuid function 0x0001 on IDT Winchip-C6 and
> Winchip2.
> 
> I think %ecx  should properly contain 0x, but it instead puts
> the 'auls' characters from cpuid function 0x (vendor string
> 'CentaurHauls') in %ecx:
> 
> %ebx = 0x746e6543 = "Cent"
> %edx = 0x48727561 = "aurH"
> %ecx = 0x736c7561 = "auls"
> 
> This sets bit 30 (0x736c7561) 'on', the 'supports rdrand' bit.
> 
> So we have to code around the vendor and chip model in this case.
> Jeffrey Walton gave some coding examples I might consider
> (https://github.com/weidai11/cryptopp/blob/master/cpu.cpp#L380).


I didn't see the start of this thread, but is it another attempt to 
re-implement /proc/cpuinfo's flags?

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




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

[systemd-devel] Antw: Re: Can I enable/disable a target?

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 09.05.2019 um 17:24
in
Nachricht <20190509152440.GC5854@gardel-login>:
> On Do, 09.05.19 12:27, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> Whenever I try to enable or disable a target (that exists), I get
>> "Failed to execute operation: No such file or directory". What file
>> or directory, please? Or what is the command trying to say?
> 
> Well, "systemctl enable" could not find the target unit file in the
> directories it searches for them. Where did you place the unit file?

Meanwhile I know: My generator was using bash, and for more reliability I
dared to add "set -u". As it turned out my version of Bash has a bug that
causes false reports of unset variables with arrays, so the generator failed
(the thread of handling exit codes of generators). As a consequence of that,
the unit file wasn't created any more (which I hadn't realized at that time).

But still combining the concepts "operation" and "No such file or directory"
is odd: An operation is neither a file nor a directory.

As said in an other thread, the preferred error message is something like
Failed to execute operation: blabla not found", where "blabla" is the unit in
question.

Regards,
Ulrich



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

[systemd-devel] Antw: Re: Wtrlt: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 09.05.2019 um 17:28
in
Nachricht <20190509152826.GD5854@gardel-login>:
> On Do, 09.05.19 15:52, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> (Sorry, I didn't sent to the list before)
>> >>> Ulrich Windl  schrieb am 09.05.2019
um 
> 14:25
>> in Nachricht <5cd44c9a.ed38.00a...@rz.uni‑regensburg.de>:
>>  Michael Biebl  schrieb am 09.05.2019 um 12:26 in
Nachricht
>> > :
>> > > Hi
>> > >
>> > > Am Do., 9. Mai 2019 um 12:22 Uhr schrieb Ulrich Windl
>> > > :
>> > >
>> > >> Despite of that I'm missing a "systemctl validate ..." command. That
way I
>> > > wouldn't need to execute start, status, stop, just to find out that
some
>> > > settings are rejected.
>> > >
>> > > There is "systemd‑analyze verify".
>>
>> > That sounds interesting, but it seems I'll have to be root to use
>> > it, and
> 
> These limitations where lifted a long time ago. Please update.

It's good to hear, unfortunatey I'm unable to do that (enterprise environment
with certified software).

Regards,
Ulrich




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

[systemd-devel] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 09.05.2019 um 17:20
in
Nachricht <20190509152036.GB5854@gardel-login>:
> On Do, 09.05.19 12:22, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> I had to subscribe to this list, even though I'm no systemd
>> fan. Still I'll have to deal with it as the distribution we use
>> switched to systemd...
> 
> Fantastic lead‑in. This is a perfect intro if you are asking for help,
> it creates the outmost desire in everyone who could help you to do so
> right‑away.

It just keeps the balance in the universe after all those "systemd is sooo
great" enthusiasm ;-)
Maybe you can make me change my mind...

> 
>> I'm porting my LSB code to systemd, and I'm having some
>> trouble. Cause of the trouble (and possible reason for systemd's
>> unpopularity) seems to be rather arbitrary restrictions without
>> reasoning (which is completely against the GNU spirit of seeking for
>> limitless software).
> 
> Hmm, the second paragaph even manages to improve upon the first. Your
> reader is now as enthusiastic as they could be to help your ASAP!

Yes, that's the "introduction to my personal frustration". I kept out the fact
that the list has a non-working "-request" address. That might add to the
overall impression I git so far...

> 
>> To be concrete: Why isn't it allowed to use an absolute path for
>> RuntimeDirectory, and wy isn't even a relative path allowed? In my
>> case I have a multi‑instance daemon, where the instances can be zero
>> to many. To avoid namespace conflicts, I created a /var/run/
>> directroy where all the instances put their stuff (in separate
>> directories each)
> 
> The "Runtime" in "RuntimeDirectory" should clarify that /run is where
> such dirs are created, hence we don't accept absolute dirs: the prefix
> must be /run, hence why specify it. If you want systemd to create a
> dir elsewhere, use StateDirectory= (which creates it in /var/lib) or
> CacheDirectory= (which creates it in /var/cache) or
> ConfigurationDirectory= which creates it in /etc.

Yes I got that once I understoood what the error message is acutally trying to
tell me ("absolute paths not allowed", you explained that earlier to me).

> 
> These four options map to the four main locations to place service
> data resources in. Well organized services only use those four places,
> since they come with clear life‑cycle and semantical definitions, and
> get first class support via the four settings. It's a gentle push that

Please let the admin decide what "well-organized" is.

> the various services follow established standards and place their
> stuff there and don't make up entirely random dirs outside of the
> typical hierarchy.

There's a difference between "random dirs" and subdirectories.

> 
> Before systemd v235 the RuntimeDirectory= setting did not support
> relative paths with "/" included. Starting with 235 it will accept
> them. Hence, please consider updating, you apparently run an older
> systemd version.

OK, so I wasn't that wrong with my claim. Unfortunately with an enterprise
distribution you don't want to install updates that make you loose support.
(The current most-recent SLES 15 is at systemd v234, unfortunately)

> 
> Note that "/var/run" is a legacy alias for "/run". It's highly
> recommended not to use the former anymore.

It it because you don't like sub-directories, or is it to save four bytes?
;-)

> 
>> Despite of that I'm missing a "systemctl validate ..." command. That
>> way I wouldn't need to execute start, status, stop, just to find out
>> that some settings are rejected.
> 
> "systemd‑analyze verify" exists. Since a long long time.

Not really: You can't verify a unit file while it's not "installed". Comare it
to validating an XML file, for example.

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



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

[systemd-devel] Antw: Re: Explain status "Loaded: not-found (Reason: No such file or directory)"

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 09.05.2019 um 17:08
in
Nachricht <20190509150818.GA5854@gardel-login>:
> On Do, 09.05.19 12:25, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) 
> wrote:
> 
>> Hi!
>>
>> I'm developing a service and getting the status of my target gives:
>> ● iotwatch.target
>>Loaded: not-found (Reason: No such file or directory)
>>Active: active since Thu 2019-05-09 12:00:56 CEST; 18min ago
>>
>> I guess it's not a file named "Reason" that's missing. Despite of my
>> recommendation to create helpful error messages, can you explain what it 
> means?
>> Even after an strace I could not find out what is missing.
> 
> "Loaded" is a field that indicates whether the unit definition was
> properly loaded from the unit file. Here, it's shown as "not-found",
> which is the value indicating that no unit file by the name
> "iotwatch.target" could be found. Then, in brackets you get some
> additional information: here "Reason:" is the field that indicates the
> reason why the unit file wasn't found, and this usually gives you a
> UNIX error code, i.e. the text string associated with an "errno"
> code. "No such file or directory" is the string for ENOENT, i.e. it's
> the simplest of cases here: there really just was no file found by the
> name you requested.
> 
> Typically, when you see "not-found" as "Loaded" value, you'll also see
> "No such file or directory" as "Reason" value, but there are some
> other cases, since units are not always synthesized from unit files on
> disk, but from other concepts too.
> 

Thanks for the explanation; it's more clear now. However I'd prefer a message
like "Loaded: iotwatch.target could not be found", so
* name what is missing, and
* use an "errno message" only for specific system calls (not to summarize
several)

Regards,
Ulrich

> Lennart
> 
> --
> Lennart Poettering, Berlin



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