[systemd-devel] [PATCH] vconsole: set font on tty16..tty63 as well

2015-02-24 Thread Jan Engelhardt
The setup program would not set the font on tty16 and upwards.
There is a maximum of 63 VCs possible in Linux. (That number is
hardcoded.)

The reason for systemd not having supported tty16+ is because it
used the VT_GETSTATE ioctl, which can only tell about the state
of the first 16 ttys. However,

However, it also seems that we do not need to rely on this
state mask. /dev/vcsN is present if it is active, and is
absent when deallocated -- at least if one is using a dynamically
managed /dev, which I suppose is a requirement of systemd anyway.
---
 src/vconsole/vconsole-setup.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bf681d9..d43b69f 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -181,20 +181,21 @@ static void font_copy_to_all_vcs(int fd) {
 struct unipair unipairs[USHRT_MAX];
 int i, r;
 
-/* get active, and 16 bit mask of used VT numbers */
+/* get active tty - ignore v_state bitmask */
 r = ioctl(fd, VT_GETSTATE, vcs);
 if (r  0)
 return;
 
-for (i = 1; i = 15; i++) {
+for (i = 1; i  64; ++i) {
 char vcname[16];
 _cleanup_close_ int vcfd = -1;
 struct console_font_op cfo = {};
 
-if (i == vcs.v_active)
-continue;
-
-/* skip non-allocated ttys */
+/*
+ * Skip non-allocated ttys. Rather than using the 16-bit-only
+ * vcs.v_state, look at the presence of the device file to
+ * determine whether it is active or not.
+ */
 snprintf(vcname, sizeof(vcname), /dev/vcs%i, i);
 if (access(vcname, F_OK)  0)
 continue;
-- 
2.1.4

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


Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device

2015-02-24 Thread Jan Synacek
Andrei Borzenkov arvidj...@gmail.com writes:

 В Fri, 20 Feb 2015 10:56:41 +0100
 Jan Synacek jsyna...@redhat.com пишет:

 First version of the patch that allows rd.luks.key to be specified almost 
 the same way as dracut can
 read it.
 

 This sounds like working around dracut bug. Dracut already has code to
 deal with it, it updates /etc/crypttab and reload systemd to run
 generators but it completely ignores keyfile parameter in non-systemd
 branch.

 The code in dracut for systemd-enabled case does

 echo $luks $dev - timeout=0,$allowdiscards  /etc/crypttab
 systemctl daemon-reload
 systemctl start cryptsetup.target

 which means it won't even use keyfile anyway.

 Why do not you simply mount device here? Dracut already has code to
 temporary mount keyfile device in non-systemd-enabled case, you can
 simply reuse it.

I've done some digging around and...

I don't get it. It makes sense to put the functionality to dracut, so
why is this implemented *differently* in both dracut and systemd? Why is
there code to make this systemd-independent task in a systemd-enabled
and non-systemd-enabled case? It's quite confusing.

 The solution creates a temporary mount unit mnt.mount that the generated 
 cryptsetup service wants.
 The partition where the keyfile is then mounted to /mnt and the absolute 
 path to the keyfile is
 changed so it points to this temporary mount instead.
 
 I'm not sure if temporarily mounting something to /mnt in initrd is safe. If 
 not, what would be a
 preffered way to do this?
 

 Dracut creates unique name for it already.

Ok, I found the code. Thanks for the pointers!

 Also, there's a problem that I'm not sure how to solve. If the 
 keyfile_device is somehow
 misspecified (for example, the uuid simply isn't valid), the boot stalls. I 
 believe that this was
 one of the problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I 
 was thinking about
 using udev to verify the uuid and its device, but I'm not sure if this makes 
 sense to do in
 initrd. Any pointers would be appreciated.
 
 Once the above problems are sorted out, an extension of this patch (perhaps 
 another patch?) would be
 to also support the third argument that rd.luks.key can take in dracut.
 
 Jan Synacek (1):
   cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
 
  src/cryptsetup/cryptsetup-generator.c | 163 
 +++---
  1 file changed, 150 insertions(+), 13 deletions(-)
 


-- 
Jan Synacek
Software Engineer, Red Hat


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


Re: [systemd-devel] [systemd-commits] configure.ac

2015-02-24 Thread David Herrmann
Hi

On Tue, Feb 24, 2015 at 4:15 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Tue, Feb 24, 2015 at 04:08:17PM +0100, David Herrmann wrote:
 Hi

 On Tue, Feb 24, 2015 at 4:07 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Tue, Feb 24, 2015 at 07:02:49AM -0800, David Herrmann wrote:
   configure.ac |1 +
   1 file changed, 1 insertion(+)
 
  New commits:
  commit 0a98d66159e474915afd6597d3aa444a698fdd2d
  Author: David Herrmann dh.herrm...@gmail.com
  Date:   Tue Feb 24 15:59:06 2015 +0100
 
  build: add -Wno-format-signedness
 
  gcc5 introduced this option (gcc4 silently ignores it, which is fine).
  Given that gcc5 thinks 'unsigned char'/'unsigned short' is promoted to
  'int' for var-args, stuff like this spits out warnings:
  uint8_t x;
  printf(% PRIu8, x);
 
  gcc5 promots 'x' to 'int', instead of 'unsigned int' and thus gets a
  signedness-warnings as it expects an 'unsigned int'.
 
  glibc states otherwise: unsigneds are always promoted to 'unsigned 
  int'.
  Until gcc and glibc figure this out, lets just ignore that warning 
  (which
  is totally useless in its current form).
 
  diff --git a/configure.ac b/configure.ac
  index 9a2235b..22a6f17 100644
  --- a/configure.ac
  +++ b/configure.ac
  @@ -186,6 +186,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
   -Wno-unused-parameter \
   -Wno-missing-field-initializers \
   -Wno-unused-result \
  +-Wno-format-signedness \
  This doesn't really work, as discussed previously on the list.

 Why? Works fine with gcc4 and gcc5 here. What's the problem exactly?
 Positive version of the option must be used to detect reliably.

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63499

Do we care? I mean I prefer a warning about unknown command-line
options over thousands of warnings regarding totally useless (and imo
wrong) signedness-mismatches. Furthermore, the warning is only printed
if there's another warning.

I can have a look at adding a CC_CHECK_NO_WARNING_APPEND() or
something like that, which properly tests for the non-negated version.

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [systemd-commits] configure.ac

2015-02-24 Thread David Herrmann
Hi

On Tue, Feb 24, 2015 at 4:07 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Tue, Feb 24, 2015 at 07:02:49AM -0800, David Herrmann wrote:
  configure.ac |1 +
  1 file changed, 1 insertion(+)

 New commits:
 commit 0a98d66159e474915afd6597d3aa444a698fdd2d
 Author: David Herrmann dh.herrm...@gmail.com
 Date:   Tue Feb 24 15:59:06 2015 +0100

 build: add -Wno-format-signedness

 gcc5 introduced this option (gcc4 silently ignores it, which is fine).
 Given that gcc5 thinks 'unsigned char'/'unsigned short' is promoted to
 'int' for var-args, stuff like this spits out warnings:
 uint8_t x;
 printf(% PRIu8, x);

 gcc5 promots 'x' to 'int', instead of 'unsigned int' and thus gets a
 signedness-warnings as it expects an 'unsigned int'.

 glibc states otherwise: unsigneds are always promoted to 'unsigned int'.
 Until gcc and glibc figure this out, lets just ignore that warning (which
 is totally useless in its current form).

 diff --git a/configure.ac b/configure.ac
 index 9a2235b..22a6f17 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -186,6 +186,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
  -Wno-unused-parameter \
  -Wno-missing-field-initializers \
  -Wno-unused-result \
 +-Wno-format-signedness \
 This doesn't really work, as discussed previously on the list.

Why? Works fine with gcc4 and gcc5 here. What's the problem exactly?

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [systemd-commits] configure.ac

2015-02-24 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Feb 24, 2015 at 04:08:17PM +0100, David Herrmann wrote:
 Hi
 
 On Tue, Feb 24, 2015 at 4:07 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Tue, Feb 24, 2015 at 07:02:49AM -0800, David Herrmann wrote:
   configure.ac |1 +
   1 file changed, 1 insertion(+)
 
  New commits:
  commit 0a98d66159e474915afd6597d3aa444a698fdd2d
  Author: David Herrmann dh.herrm...@gmail.com
  Date:   Tue Feb 24 15:59:06 2015 +0100
 
  build: add -Wno-format-signedness
 
  gcc5 introduced this option (gcc4 silently ignores it, which is fine).
  Given that gcc5 thinks 'unsigned char'/'unsigned short' is promoted to
  'int' for var-args, stuff like this spits out warnings:
  uint8_t x;
  printf(% PRIu8, x);
 
  gcc5 promots 'x' to 'int', instead of 'unsigned int' and thus gets a
  signedness-warnings as it expects an 'unsigned int'.
 
  glibc states otherwise: unsigneds are always promoted to 'unsigned 
  int'.
  Until gcc and glibc figure this out, lets just ignore that warning 
  (which
  is totally useless in its current form).
 
  diff --git a/configure.ac b/configure.ac
  index 9a2235b..22a6f17 100644
  --- a/configure.ac
  +++ b/configure.ac
  @@ -186,6 +186,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
   -Wno-unused-parameter \
   -Wno-missing-field-initializers \
   -Wno-unused-result \
  +-Wno-format-signedness \
  This doesn't really work, as discussed previously on the list.
 
 Why? Works fine with gcc4 and gcc5 here. What's the problem exactly?
Positive version of the option must be used to detect reliably.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63499

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


[systemd-devel] [PATCH 2/2] vconsole: set font on tty16..tty63 as well

2015-02-24 Thread Jan Engelhardt
The setup program would not set the font on tty16 upwards.
There is a maximum of 63 VCs possible in Linux. (That number is
hardcoded.)
---
 src/vconsole/vconsole-setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/vconsole/vconsole-setup.c b/src/vconsole/vconsole-setup.c
index bf681d9..0cf9776 100644
--- a/src/vconsole/vconsole-setup.c
+++ b/src/vconsole/vconsole-setup.c
@@ -186,7 +186,7 @@ static void font_copy_to_all_vcs(int fd) {
 if (r  0)
 return;
 
-for (i = 1; i = 15; i++) {
+for (i = 1; i  64; ++i) {
 char vcname[16];
 _cleanup_close_ int vcfd = -1;
 struct console_font_op cfo = {};
-- 
2.1.4

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


Re: [systemd-devel] [PATCH 2/2] vconsole: set font on tty16..tty63 as well

2015-02-24 Thread Lennart Poettering
On Tue, 24.02.15 17:49, Jan Engelhardt (jeng...@inai.de) wrote:

 The setup program would not set the font on tty16 upwards.
 There is a maximum of 63 VCs possible in Linux. (That number is
 hardcoded.)

We deliberately do not support such high VTs in systemds. If you want
such high VTs, then please patch this downstream. 

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] [PATCH 2/2] vconsole: set font on tty16..tty63 as well

2015-02-24 Thread Jan Engelhardt
On Tuesday 2015-02-24 19:47, Lennart Poettering wrote:

On Tue, 24.02.15 17:49, Jan Engelhardt (jeng...@inai.de) wrote:

 The setup program would not set the font on tty16 upwards.
 There is a maximum of 63 VCs possible in Linux. (That number is
 hardcoded.)

We deliberately do not support such high VTs in systemds.

And what's the rationale?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] configure: turn off -Wlogical-not-parentheses

2015-02-24 Thread David Herrmann
Hi

On Mon, Feb 16, 2015 at 11:02 PM, Shawn Landden sh...@churchofgit.com wrote:
 Introduced in gcc-5

 These errors are really annoying. I can get behind clarification of nested 
 ifs,
 but this is overkill.
 ---
  configure.ac | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/configure.ac b/configure.ac
 index 97a29d6..e646db7 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -187,6 +187,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
  -Wno-unused-parameter \
  -Wno-missing-field-initializers \
  -Wno-unused-result \
 +-Wno-logical-not-parentheses \
  -Werror=overflow \
  -Wdate-time \
  -Wnested-externs \

I fixed the -Wno-* detection today. Is this patch still needed? I
don't have gcc5 here, but I think Daniel fixed most of those warnings
recently and they turned out to be real bugs. So should I still apply
it?

Thanks
David

 --
 2.2.1.209.g41e5f3a

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


Re: [systemd-devel] [systemd-commits] configure.ac

2015-02-24 Thread David Herrmann
Hey

On Tue, Feb 24, 2015 at 4:20 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Tue, Feb 24, 2015 at 4:15 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
 On Tue, Feb 24, 2015 at 04:08:17PM +0100, David Herrmann wrote:
 Hi

 On Tue, Feb 24, 2015 at 4:07 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Tue, Feb 24, 2015 at 07:02:49AM -0800, David Herrmann wrote:
   configure.ac |1 +
   1 file changed, 1 insertion(+)
 
  New commits:
  commit 0a98d66159e474915afd6597d3aa444a698fdd2d
  Author: David Herrmann dh.herrm...@gmail.com
  Date:   Tue Feb 24 15:59:06 2015 +0100
 
  build: add -Wno-format-signedness
 
  gcc5 introduced this option (gcc4 silently ignores it, which is 
  fine).
  Given that gcc5 thinks 'unsigned char'/'unsigned short' is promoted 
  to
  'int' for var-args, stuff like this spits out warnings:
  uint8_t x;
  printf(% PRIu8, x);
 
  gcc5 promots 'x' to 'int', instead of 'unsigned int' and thus gets a
  signedness-warnings as it expects an 'unsigned int'.
 
  glibc states otherwise: unsigneds are always promoted to 'unsigned 
  int'.
  Until gcc and glibc figure this out, lets just ignore that warning 
  (which
  is totally useless in its current form).
 
  diff --git a/configure.ac b/configure.ac
  index 9a2235b..22a6f17 100644
  --- a/configure.ac
  +++ b/configure.ac
  @@ -186,6 +186,7 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
   -Wno-unused-parameter \
   -Wno-missing-field-initializers \
   -Wno-unused-result \
  +-Wno-format-signedness \
  This doesn't really work, as discussed previously on the list.

 Why? Works fine with gcc4 and gcc5 here. What's the problem exactly?
 Positive version of the option must be used to detect reliably.

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63499

 Do we care? I mean I prefer a warning about unknown command-line
 options over thousands of warnings regarding totally useless (and imo
 wrong) signedness-mismatches. Furthermore, the warning is only printed
 if there's another warning.

 I can have a look at adding a CC_CHECK_NO_WARNING_APPEND() or
 something like that, which properly tests for the non-negated version.

I now fixed CC_CHECK_FLAG_APPEND. If someone knows m4+bash hacking
well, please review that:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=43bbf1acc8202de895e5449828a7b863c69fcc2f

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] unaligned write in dhcp_identifier_set_iaid

2015-02-24 Thread Michael Olbrich
Hi,

there is an unaligned write in dhcp_identifier_set_iaid() and I'm not quite
sure what the correct fix is:

int dhcp_identifier_set_iaid(int ifindex, uint8_t *mac, size_t mac_len, 
uint32_t *_id) {
[...]
*_id = (id  0x) ^ (id  32);
[...]
}

And this is called with:
r = dhcp_identifier_set_iaid(client-index, client-mac_addr, 
client-mac_addr_len, client-client_id.ns.iaid);

And iaid is not unaligned because of the packing in struct sd_dhcp_client.
I'm not sure why '_packed_' is used there. It this just to save some space,
or is there a reason for this?

Regards,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] vconsole: rerun setup on console takeovers as well

2015-02-24 Thread Jan Engelhardt
When a system, which has an FB driver and fbcon loaded and active,
then the font state gets lost on console takeovers, as for example
issued by i915. Since fbcon remains loaded and active, the existing
event handling (add/vtcon*) is not sufficient.
---
This goes on top of the other patchset I sent earlier.
 [PATCH 1/2] vconsole: match on vtcon events, not fbcon ones

 src/vconsole/90-vconsole.rules.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/vconsole/90-vconsole.rules.in 
b/src/vconsole/90-vconsole.rules.in
index 35b9ad5..e05ecbf 100644
--- a/src/vconsole/90-vconsole.rules.in
+++ b/src/vconsole/90-vconsole.rules.in
@@ -8,3 +8,7 @@
 # Each vtcon keeps its own state of fonts.
 #
 ACTION==add, SUBSYSTEM==vtconsole, KERNEL==vtcon*, 
RUN+=@rootlibexecdir@/systemd-vconsole-setup
+
+# Handle the case of console takeover where the fb device is replaced.
+#
+ACTION==add, SUBSYSTEM==graphics, KERNEL==fb[0-9]*, 
RUN+=@rootlibexecdir@/systemd-vconsole-setup
-- 
2.1.4

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


[systemd-devel] Enable port forwarding via upnp

2015-02-24 Thread Kai Krakow
Hello!

Is it possible to somehow create a service which enables port forwardings on 
my router using upnp? Currently, I guess it is not possible (except maybe 
using ExecPost or ExecPre and the upnpc program). But when my client IP 
changes via DHCP, it should be reapplied. Also, it needs to be maintained as 
the programmed port forwardings would timeout and be cleared from the router 
after a while. So it needs to be hooked up to systemd-networkd somehow (at 
least that is what I am using).

So I guess this logic should be built into systemd-networkd, maybe offering 
some dbus interface also. And service and/or socket files could have a flag 
to enable upnp forwards. This way, systemd-networkd knows about the 
registered forwards and maintains them, and systemd will trigger 
registration/unregistration on it whenever services start or stop which have 
such flags enabled. By using dbus, this could be an interface implemented by 
other network management daemons, too.

Is this the way to go? I may be willing to help implementing a patch for 
this, though I am absolutely not familiar with dbus programming and the 
security measures involved.

I just wanted to ask first, if it makes sense at all - or if there's already 
a way to do it by creating a combination of timer and service units which 
are triggered by systemd-networkd events somehow.

Please advice and tell your thoughts. Maybe it is just plain insane...

-- 
Replies to list only preferred.

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


[systemd-devel] machinectl create container via dbus

2015-02-24 Thread Vasiliy Tolstov
Hello =). I'm try to think about creating containers with
systemd-nspawn and machinectl from dbus. Does it possibe?

I need dbus because i have unprivileged app, that needs to create
container and run it. I'm try libvirt, but it does not have ability to
download image (only possible to use already prepared directory or
downloaded image)

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Improve log notice when unprivileged users run journalctl executable

2015-02-24 Thread Gautier Pelloux-Prayer
Hi,

Currently, when user runs journalctl without extra privileges, output
will be:

No journal files were found.

This patch modifies this sentence to give some hints to the user:

No journal files were found. Users in the 'systemd-journal' group
may access more messages.

It should help new comers to understand that some extra privileges can
be useful to retrieve logs.

/Gautier

diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 56435ff..7f4c160 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -1581,12 +1581,13 @@ static int access_check(sd_journal *j) {
 Iterator it;
 void *code;
 int r = 0;
-
+bool is_privileged = (geteuid() == 0) ||
(in_group(systemd-journal)  0);
 assert(j);
 
 if (set_isempty(j-errors)) {
 if (ordered_hashmap_isempty(j-files))
-log_notice(No journal files were found.);
+log_notice(No journal files were found.%s,
+  is_privileged?: Users in the
'systemd-journal' group may access more messages.);
 return 0;
 }
 
@@ -1594,9 +1595,7 @@ static int access_check(sd_journal *j) {
 #ifdef HAVE_ACL
 /* If /var/log/journal doesn't even exist,
  * unprivileged users have no access at all */
-if (access(/var/log/journal, F_OK)  0 
-geteuid() != 0 
-in_group(systemd-journal) = 0) {
+if (access(/var/log/journal, F_OK)  0  !
is_privileged) {
 log_error(Unprivileged users cannot access
messages, unless persistent log storage is\n
   enabled. Users in the
'systemd-journal' group may always access messages.);
 return -EACCES;
@@ -1610,7 +1609,7 @@ static int access_check(sd_journal *j) {
 return r;
 }
 #else
-if (geteuid() != 0  in_group(systemd-journal) = 0)
{
+if (!is_privileged) {
 log_error(Unprivileged users cannot access
messages. Users in the 'systemd-journal' group\n
   group may access messages.);
 return -EACCES;



From 0f973d231d057866d8626e680b80bded24103af0 Mon Sep 17 00:00:00 2001
From: Gautier Pelloux-Prayer gautier+...@damsy.net
Date: Sun, 11 Jan 2015 12:00:18 +0100
Subject: [PATCH] Improve log notice when unprivileged users run journalctl
 executable

---
 src/journal/journalctl.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 56435ff..7f4c160 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -1581,12 +1581,13 @@ static int access_check(sd_journal *j) {
 Iterator it;
 void *code;
 int r = 0;
-
+bool is_privileged = (geteuid() == 0) || (in_group(systemd-journal)  0);
 assert(j);
 
 if (set_isempty(j-errors)) {
 if (ordered_hashmap_isempty(j-files))
-log_notice(No journal files were found.);
+log_notice(No journal files were found.%s,
+  is_privileged?: Users in the 'systemd-journal' group may access more messages.);
 return 0;
 }
 
@@ -1594,9 +1595,7 @@ static int access_check(sd_journal *j) {
 #ifdef HAVE_ACL
 /* If /var/log/journal doesn't even exist,
  * unprivileged users have no access at all */
-if (access(/var/log/journal, F_OK)  0 
-geteuid() != 0 
-in_group(systemd-journal) = 0) {
+if (access(/var/log/journal, F_OK)  0  !is_privileged) {
 log_error(Unprivileged users cannot access messages, unless persistent log storage is\n
   enabled. Users in the 'systemd-journal' group may always access messages.);
 return -EACCES;
@@ -1610,7 +1609,7 @@ static int access_check(sd_journal *j) {
 return r;
 }
 #else
-if (geteuid() != 0  in_group(systemd-journal) = 0) {
+if (!is_privileged) {
 log_error(Unprivileged users cannot access messages. Users in the 'systemd-journal' group\n
   group may access messages.);
 return -EACCES;
-- 
2.1.4

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


Re: [systemd-devel] [PATCH] systemd: add getrandom syscall numbers for MIPS

2015-02-24 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Feb 23, 2015 at 04:01:31PM +0200, Aaro Koskinen wrote:
 Add getrandom syscall numbers for MIPS. Based on Linux 3.17 kernel
 (commit 42944521af97a3b25516f15f3149aec3779656dc, MIPS: Wire up new
 syscalls getrandom and memfd_create).
 
 Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
No need for SOB.

Applied.

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


Re: [systemd-devel] [PATCH] po: update Italian translation

2015-02-24 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Feb 19, 2015 at 05:03:51PM +0100, Daniele Medri wrote:
 ---
  po/it.po | 158 
 +++
  1 file changed, 109 insertions(+), 49 deletions(-)
Thanks, applied.

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


Re: [systemd-devel] [RFC] core, login: wording

2015-02-24 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Feb 20, 2015 at 11:01:18AM +0100, Daniele Medri wrote:
 ---
  src/core/org.freedesktop.systemd1.policy.in.in | 6 +++---
  src/login/org.freedesktop.login1.policy.in | 8 
  2 files changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/src/core/org.freedesktop.systemd1.policy.in.in 
 b/src/core/org.freedesktop.systemd1.policy.in.in
 index cc39a9e..11a27de 100644
 --- a/src/core/org.freedesktop.systemd1.policy.in.in
 +++ b/src/core/org.freedesktop.systemd1.policy.in.in
 @@ -39,7 +39,7 @@
  
  action id=org.freedesktop.systemd1.manage-unit-files
  _descriptionManage system service or unit 
 files/_description
 -_messageAuthentication is required to manage system 
 service or unit files./_message
 +_messageAuthentication is required to handle system 
 service or unit files./_mes
Doesn't seem to be an improvment.

sage
  defaults
  allow_anyauth_admin/allow_any
  allow_inactiveauth_admin/allow_inactive
 @@ -48,8 +48,8 @@
  /action
  
  action id=org.freedesktop.systemd1.set-environment
 -_descriptionSet or unset system and service manager 
 environment variables/_description
 +_descriptionConfigure system and service manager 
 environment variables/_description
This is less specific than the original. I'd say that it is worse.

 -_messageAuthentication is required to set or unset system 
 and service manager environment variables./_message
 +_messageAuthentication is required to handle system and 
 service manager environment variables./_message
This one too. handle could mean anything. set or unset is maybe not pretty, 
but
at least very clear.

  defaults
  allow_anyauth_admin/allow_any
  allow_inactiveauth_admin/allow_inactive
 diff --git a/src/login/org.freedesktop.login1.policy.in 
 b/src/login/org.freedesktop.login1.policy.in
 index 35bb390..906fea2 100644
 --- a/src/login/org.freedesktop.login1.policy.in
 +++ b/src/login/org.freedesktop.login1.policy.in
 @@ -271,8 +271,8 @@
  /action
  
  action id=org.freedesktop.login1.manage
 -_descriptionManager active sessions, users and 
 seats/_description
 +_descriptionActive sessions, users and seats 
 management/_description
I think this was just a typo, extra r, and the original wording is OK.
This was actually already fixed in git.

 -_messageAuthentication is required for managing active 
 sessions, users and seats./_message
 +_messageAuthentication is required to handle active 
 sessions, users and seats./_message
  defaults
  allow_anyauth_admin_keep/allow_any
  allow_inactiveauth_admin_keep/allow_inactive
 @@ -281,8 +281,8 @@
  /action
  
  action id=org.freedesktop.login1.lock-sessions
 -_descriptionLock or unlock active sessions/_description
 -_messageAuthentication is required for locking or 
 unlocking active sessions./_message
 +_descriptionActive sessions management/_description
 +_messageAuthentication is required to handle active 
 sessions./_message
Less specific.

But we should say to lock or unlock. I'll fix that.

All in all, I think there's nothing to fix here.

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


Re: [systemd-devel] [PATCH] bootchart: svg: fix checking of list end

2015-02-24 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Feb 24, 2015 at 06:32:31PM +0200, Aaro Koskinen wrote:
 If we have less samples than expected, systemd-bootchart will crash.
 
 Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
No need for SOB.

 ---
  src/bootchart/svg.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
 index e111fa9..144177c 100644
 --- a/src/bootchart/svg.c
 +++ b/src/bootchart/svg.c
 @@ -1170,7 +1170,7 @@ static void svg_ps_bars(void) {
  
  ps-sample = ps-sample-next;
  sample_hz = ps-sample;
 -for (ii=0;((ii(int)arg_hz/2)(ps-sample-next));ii++)
 +for (ii=0;((ii(int)arg_hz/2)(sample_hz-next));ii++)
  sample_hz = sample_hz-next;
Applied.

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