[systemd-devel] [PATCH 2/3] man: Unify title for configuration files
--- man/hostname.xml | 2 +- man/localtime.xml | 2 +- man/machine-id.xml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/man/hostname.xml b/man/hostname.xml index 84a2961..f89332e 100644 --- a/man/hostname.xml +++ b/man/hostname.xml @@ -24,7 +24,7 @@ refentry id=hostname refentryinfo -title/etc/hostname/title +titlehostname/title productnamesystemd/productname authorgroup diff --git a/man/localtime.xml b/man/localtime.xml index 88c84a3..d3da4ed 100644 --- a/man/localtime.xml +++ b/man/localtime.xml @@ -25,7 +25,7 @@ refentry id=localtime refentryinfo -title/etc/localtime/title +titlelocaltime/title productnamesystemd/productname authorgroup diff --git a/man/machine-id.xml b/man/machine-id.xml index 7d424b7..153ae4d 100644 --- a/man/machine-id.xml +++ b/man/machine-id.xml @@ -24,7 +24,7 @@ refentry id=machine-id refentryinfo -title/etc/machine-id/title +titlemachine-id/title productnamesystemd/productname authorgroup -- 1.8.1.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] man: Fix id attributes
--- man/sd-readahead.xml | 2 +- man/sd_readahead.xml | 2 +- man/systemd-activate.xml | 2 +- man/systemd-update-utmp-runlevel.service.xml | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/man/sd-readahead.xml b/man/sd-readahead.xml index ee7c936..f8a0a0b 100644 --- a/man/sd-readahead.xml +++ b/man/sd-readahead.xml @@ -21,7 +21,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=sd-daemon conditional='ENABLE_READAHEAD' +refentry id=sd-readahead conditional='ENABLE_READAHEAD' refentryinfo titlesd-readahead/title diff --git a/man/sd_readahead.xml b/man/sd_readahead.xml index 39e3469..c26d5c6 100644 --- a/man/sd_readahead.xml +++ b/man/sd_readahead.xml @@ -21,7 +21,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=sd_notify conditional='ENABLE_READAHEAD' +refentry id=sd_readahead conditional='ENABLE_READAHEAD' refentryinfo titlesd_readahead/title diff --git a/man/systemd-activate.xml b/man/systemd-activate.xml index 6949731..a5cab8e 100644 --- a/man/systemd-activate.xml +++ b/man/systemd-activate.xml @@ -21,7 +21,7 @@ You should have received a copy of the GNU Lesser General Public License along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=systemd-journal-gatewayd.service +refentry id=systemd-activate refentryinfo titlesystemd-activate/title diff --git a/man/systemd-update-utmp-runlevel.service.xml b/man/systemd-update-utmp-runlevel.service.xml index 0e19581..867b958 100644 --- a/man/systemd-update-utmp-runlevel.service.xml +++ b/man/systemd-update-utmp-runlevel.service.xml @@ -19,7 +19,7 @@ You should have received a copy of the GNU Lesser General Public License along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=systemd-user-sessions.service +refentry id=systemd-update-utmp-runlevel.service refentryinfo titlesystemd-update-utmp-runlevel.service/title -- 1.8.1.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] util: Fix grammar in comment
---
src/shared/util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index b7ba7fb..c493a34 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -3607,8 +3607,8 @@ void execute_directory(const char *directory, DIR *d,
char *argv[]) {
assert(directory);
-/* Executes all binaries in a directory in parallel and waits
- * until all they all finished. */
+/* Executes all binaries in a directory in parallel and
+ * waits for them to finish. */
if (!d) {
if (!(_d = opendir(directory))) {
--
1.8.1.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] man: Fix id attributes
On Thu, 07.03.13 15:12, Jan Janssen (medhe...@web.de) wrote: Thanks! Applied all three! --- man/sd-readahead.xml | 2 +- man/sd_readahead.xml | 2 +- man/systemd-activate.xml | 2 +- man/systemd-update-utmp-runlevel.service.xml | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/man/sd-readahead.xml b/man/sd-readahead.xml index ee7c936..f8a0a0b 100644 --- a/man/sd-readahead.xml +++ b/man/sd-readahead.xml @@ -21,7 +21,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=sd-daemon conditional='ENABLE_READAHEAD' +refentry id=sd-readahead conditional='ENABLE_READAHEAD' refentryinfo titlesd-readahead/title diff --git a/man/sd_readahead.xml b/man/sd_readahead.xml index 39e3469..c26d5c6 100644 --- a/man/sd_readahead.xml +++ b/man/sd_readahead.xml @@ -21,7 +21,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=sd_notify conditional='ENABLE_READAHEAD' +refentry id=sd_readahead conditional='ENABLE_READAHEAD' refentryinfo titlesd_readahead/title diff --git a/man/systemd-activate.xml b/man/systemd-activate.xml index 6949731..a5cab8e 100644 --- a/man/systemd-activate.xml +++ b/man/systemd-activate.xml @@ -21,7 +21,7 @@ You should have received a copy of the GNU Lesser General Public License along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=systemd-journal-gatewayd.service +refentry id=systemd-activate refentryinfo titlesystemd-activate/title diff --git a/man/systemd-update-utmp-runlevel.service.xml b/man/systemd-update-utmp-runlevel.service.xml index 0e19581..867b958 100644 --- a/man/systemd-update-utmp-runlevel.service.xml +++ b/man/systemd-update-utmp-runlevel.service.xml @@ -19,7 +19,7 @@ You should have received a copy of the GNU Lesser General Public License along with systemd; If not, see http://www.gnu.org/licenses/. -- -refentry id=systemd-user-sessions.service +refentry id=systemd-update-utmp-runlevel.service refentryinfo titlesystemd-update-utmp-runlevel.service/title Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemctl: mangle unit name in is-enabled
---
src/systemctl/systemctl.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 99286cf..72e9c55 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3982,6 +3982,7 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
DBusMessage _cleanup_dbus_message_unref_ *reply = NULL;
bool enabled;
char **name;
+char *n;
dbus_error_init(error);
@@ -3996,7 +3997,14 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
STRV_FOREACH(name, args+1) {
UnitFileState state;
-state = unit_file_get_state(arg_scope, arg_root,
*name);
+n = unit_name_mangle(*name);
+if (!n)
+return log_oom();
+
+state = unit_file_get_state(arg_scope, arg_root, n);
+
+free(n);
+
if (state 0)
return state;
@@ -4013,6 +4021,10 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
STRV_FOREACH(name, args+1) {
const char *s;
+n = unit_name_mangle(*name);
+if (!n)
+return log_oom();
+
r = bus_method_call_with_reply (
bus,
org.freedesktop.systemd1,
@@ -4021,8 +4033,11 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
GetUnitFileState,
reply,
NULL,
-DBUS_TYPE_STRING, name,
+DBUS_TYPE_STRING, n,
DBUS_TYPE_INVALID);
+
+free(n);
+
if (r)
return r;
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] bootchart: use _cleanup_fclose_
On Thu, 07.03.13 08:52, har...@redhat.com (har...@redhat.com) wrote:
From: Harald Hoyer har...@redhat.com
Applied all three! Thanks!
---
src/bootchart/log.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/src/bootchart/log.c b/src/bootchart/log.c
index 43999f2..ccec03f 100644
--- a/src/bootchart/log.c
+++ b/src/bootchart/log.c
@@ -57,7 +57,7 @@ double gettime_ns(void)
void log_uptime(void)
{
-FILE *f;
+FILE _cleanup_fclose_ *f = NULL;
char str[32];
double uptime;
@@ -65,11 +65,9 @@ void log_uptime(void)
if (!f)
return;
-if (!fscanf(f, %s %*s, str)) {
-fclose(f);
+if (!fscanf(f, %s %*s, str))
return;
-}
-fclose(f);
+
uptime = strtod(str, NULL);
log_start = gettime_ns();
@@ -120,7 +118,6 @@ void log_sample(int sample)
{
static int vmstat;
static int schedstat;
-FILE *st;
char buf[4095];
char key[256];
char val[256];
@@ -253,6 +250,7 @@ schedstat_next:
/* end of our LL? then append a new record */
if (ps-pid != pid) {
+FILE _cleanup_fclose_ *st = NULL;
char t[32];
struct ps_struct *parent;
@@ -320,10 +318,8 @@ schedstat_next:
if (!st)
continue;
if (!fscanf(st, %*s %*s %*s %i, p)) {
-fclose(st);
continue;
}
-fclose(st);
ps-ppid = p;
/*
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: mangle unit name in is-enabled
On Thu, 07.03.13 16:09, Lukas Nykryn (lnyk...@redhat.com) wrote:
Hmm, don't we need the same for the other unit file verbs such as
enable/disable/mask/unmask, too?
---
src/systemctl/systemctl.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 99286cf..72e9c55 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3982,6 +3982,7 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
DBusMessage _cleanup_dbus_message_unref_ *reply = NULL;
bool enabled;
char **name;
+char *n;
dbus_error_init(error);
@@ -3996,7 +3997,14 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
STRV_FOREACH(name, args+1) {
UnitFileState state;
-state = unit_file_get_state(arg_scope, arg_root,
*name);
+n = unit_name_mangle(*name);
+if (!n)
+return log_oom();
+
+state = unit_file_get_state(arg_scope, arg_root, n);
+
+free(n);
+
if (state 0)
return state;
@@ -4013,6 +4021,10 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
STRV_FOREACH(name, args+1) {
const char *s;
+n = unit_name_mangle(*name);
+if (!n)
+return log_oom();
+
r = bus_method_call_with_reply (
bus,
org.freedesktop.systemd1,
@@ -4021,8 +4033,11 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
GetUnitFileState,
reply,
NULL,
-DBUS_TYPE_STRING, name,
+DBUS_TYPE_STRING, n,
DBUS_TYPE_INVALID);
+
+free(n);
+
if (r)
return r;
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: mangle unit name in is-enabled
Čt 7. březen 2013, 16:13:17 CET, Lennart Poettering napsal:
On Thu, 07.03.13 16:09, Lukas Nykryn (lnyk...@redhat.com) wrote:
Hmm, don't we need the same for the other unit file verbs such as
enable/disable/mask/unmask, too?
---
src/systemctl/systemctl.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 99286cf..72e9c55 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3982,6 +3982,7 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
DBusMessage _cleanup_dbus_message_unref_ *reply = NULL;
bool enabled;
char **name;
+char *n;
dbus_error_init(error);
@@ -3996,7 +3997,14 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
STRV_FOREACH(name, args+1) {
UnitFileState state;
-state = unit_file_get_state(arg_scope, arg_root,
*name);
+n = unit_name_mangle(*name);
+if (!n)
+return log_oom();
+
+state = unit_file_get_state(arg_scope, arg_root, n);
+
+free(n);
+
if (state 0)
return state;
@@ -4013,6 +4021,10 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
STRV_FOREACH(name, args+1) {
const char *s;
+n = unit_name_mangle(*name);
+if (!n)
+return log_oom();
+
r = bus_method_call_with_reply (
bus,
org.freedesktop.systemd1,
@@ -4021,8 +4033,11 @@ static int unit_is_enabled(DBusConnection *bus, char
**args) {
GetUnitFileState,
reply,
NULL,
-DBUS_TYPE_STRING, name,
+DBUS_TYPE_STRING, n,
DBUS_TYPE_INVALID);
+
+free(n);
+
if (r)
return r;
Lennart
I think that these already work.
Lukas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: mangle unit name in is-enabled
On Thu, 07.03.13 16:18, Lukáš Nykrýn (lnyk...@redhat.com) wrote: I think that these already work. Oh, indeed. I was confused. Thanks! Applied! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journald: Make the group that owns journal files configurable
While a separate group to own the journal files is desirable, which
group it is should be tweakable (to the point where it can be set to
an existing group, like adm, for systems where that makes sense).
To this end, this patch introduces a --with-journal-group=GROUP option
to configure, and uses the supplied value (or systemd-journal, if none
specified) as the dedicated group.
Signed-off-by: Gergely Nagy alger...@balabit.hu
---
configure.ac |8
man/systemd-journald.service.xml |7 ---
src/journal/journalctl.c | 12 ++--
src/journal/journald-server.c|2 +-
4 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/configure.ac b/configure.ac
index 43b8225..47527da 100644
--- a/configure.ac
+++ b/configure.ac
@@ -793,6 +793,14 @@ AC_ARG_WITH([tty-gid],
[AC_DEFINE_UNQUOTED(TTY_GID, [$withval], [GID of the 'tty' group])],
[])
+AC_ARG_WITH([journal-group],
+[AS_HELP_STRING([--with-journal-group=GROUP],
+[Specify the group systemd-journal files should belong to])],
+[journal_group=$withval],
+[journal_group=systemd-journal])
+
+AC_DEFINE_UNQUOTED(JOURNAL_GROUP, [$journal_group], [Group of journal files
should belong to])]
+
AC_ARG_WITH([dbuspolicydir],
AS_HELP_STRING([--with-dbuspolicydir=DIR], [D-Bus policy directory]),
[],
diff --git a/man/systemd-journald.service.xml b/man/systemd-journald.service.xml
index bc32c8e..5d6c112 100644
--- a/man/systemd-journald.service.xml
+++ b/man/systemd-journald.service.xml
@@ -161,9 +161,10 @@
refsect1
titleAccess Control/title
-paraJournal files are by default owned and readable
-by the literalsystemd-journal/literal system group
-(but not writable). Adding a user to this group thus
+paraUnless configured differently, journal files are
+by default owned and readable by the
+literalsystemd-journal/literal system group (but
+not writable). Adding a user to this group thus
enables her/him to read the journal files./para
paraBy default, each logged in user will get her/his
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index c90fecd..0171859 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -870,16 +870,16 @@ static int verify(sd_journal *j) {
static int access_check(void) {
#ifdef HAVE_ACL
-if (access(/var/log/journal, F_OK) 0 geteuid() != 0
in_group(systemd-journal) = 0) {
-log_error(Unprivileged users can't see messages unless
persistent log storage is enabled. Users in the group 'systemd-journal' can
always see messages.);
+if (access(/var/log/journal, F_OK) 0 geteuid() != 0
in_group(JOURNAL_GROUP) = 0) {
+log_error(Unprivileged users can't see messages unless
persistent log storage is enabled. Users in the group '%s' can always see
messages., JOURNAL_GROUP);
return -EACCES;
}
-if (!arg_quiet geteuid() != 0 in_group(systemd-journal) = 0)
-log_warning(Showing user generated messages only. Users in
the group 'systemd-journal' can see all messages. Pass -q to turn this notice
off.);
+if (!arg_quiet geteuid() != 0 in_group(JOURNAL_GROUP) = 0)
+log_warning(Showing user generated messages only. Users in
the group '%s' can see all messages. Pass -q to turn this notice off.,
JOURNAL_GROUP);
#else
-if (geteuid() != 0 in_group(systemd-journal) = 0) {
-log_error(No access to messages. Only users in the group
'systemd-journal' can see messages.);
+if (geteuid() != 0 in_group(JOURNAL_GROUP) = 0) {
+log_error(No access to messages. Only users in the group '%s'
can see messages., JOURNAL_GROUP);
return -EACCES;
}
#endif
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index ac565c7..a933662 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -174,7 +174,7 @@ static uint64_t available_space(Server *s) {
}
static void server_read_file_gid(Server *s) {
-const char *g = systemd-journal;
+const char *g = JOURNAL_GROUP;
int r;
assert(s);
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: Make the group that owns journal files configurable
On Thu, 07.03.13 16:41, Gergely Nagy (alger...@balabit.hu) wrote: While a separate group to own the journal files is desirable, which group it is should be tweakable (to the point where it can be set to an existing group, like adm, for systems where that makes sense). To this end, this patch introduces a --with-journal-group=GROUP option to configure, and uses the supplied value (or systemd-journal, if none specified) as the dedicated group. I don't think this is really desirable. This group is something external packages should be able to make use of and rely on, and it would be suboptimal if you'd have to configure this group everywhere manually. I mean, can you make a really good case why this should be configurable? Configurability just for configurability's sake doesn't appeal to me... Note that your patch already ran into one instance of the problem of making this configureable: systemd-journal-gatewayd.service refers to this group in SupplementaryGroups= in order to get access to the journal files, which your patch didn't update. So, you see, it already made BOOM! once to have this configurable, because it was too hard to keep things in sync. So, I am very conservative on making this configurable, but hey, I can be convinced, so can you make a really good case for this? Otherwise this appears to be something to configure downstream by patching, rather then upstream via a configure switch. Hope that makes some sense, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: Make the group that owns journal files configurable
Lennart Poettering lenn...@poettering.net writes: On Thu, 07.03.13 16:41, Gergely Nagy (alger...@balabit.hu) wrote: While a separate group to own the journal files is desirable, which group it is should be tweakable (to the point where it can be set to an existing group, like adm, for systems where that makes sense). To this end, this patch introduces a --with-journal-group=GROUP option to configure, and uses the supplied value (or systemd-journal, if none specified) as the dedicated group. I don't think this is really desirable. This group is something external packages should be able to make use of and rely on, and it would be suboptimal if you'd have to configure this group everywhere manually. The main reason behind the patch is that I already have systems installed where logfiles belong to a dedicated group, and when I'll be migrating those to systemd journal, I'd like to keep the groups and not introduce yet another one that does the same thing. There's already more groups on my systems than I need, I'd like to trim them down, not introduce new ones. It *can* be considered a corner case, as I also have very few, and only trusted users, so the adm group was a perfect fit for my use case. Note that your patch already ran into one instance of the problem of making this configureable: systemd-journal-gatewayd.service refers to this group in SupplementaryGroups= in order to get access to the journal files, which your patch didn't update. So, you see, it already made BOOM! once to have this configurable, because it was too hard to keep things in sync. Yeah, my bad. Caught that a few moments after sending the patch, and started to investigate if I missed anything else too. :( That's what I get for submit first, test later. So, I am very conservative on making this configurable, but hey, I can be convinced, so can you make a really good case for this? Apart from the case I outlined above, all other reasons I'd have boil down to convenience. Similarly how the 'tty' group's ID is configurable, the journal group being similarly configurable would make it much easier downstream to adapt the journal to an existing environment. Sure, I could patch it, but... I don't like patching, it makes it harder to follow upstream in the long run. With a configure flag, I can just update my sources and rebuild. If I have to patch, I need to fix any conflicts, or even at best, refresh patches so they apply without fuzz. Will even need to pay attention to any new places the hard-coded group gets introduced aswell, and update the patch. That's a tedious job, one I'd rather avoid. Making it configurable would allow me to follow systemd more closely. Perhaps a warning can be added to the configure switch that changing it from the default may very well break external tools, or even hide the option (if that is possible with autoconf). I do understand your concern, and wholeheartedly agree that it does bear some risk, but with clear documentation or with a hidden configure flag, I think those risks are negligible, while the benefits are great for those of us who can upgrade software, but not change policy. I mean, if I have to add the users I have in the adm group to systemd-journal aswell, that means adding the group to LDAP, then updating the users too... ick. Too much work for no real gain for me. -- |8] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: Make the group that owns journal files configurable
On Thu, Mar 7, 2013 at 5:38 PM, Gergely Nagy alger...@balabit.hu wrote: Apart from the case I outlined above, all other reasons I'd have boil down to convenience. Similarly how the 'tty' group's ID is configurable, the journal group being similarly configurable would make it much easier downstream to adapt the journal to an existing environment. tty is also not configurable, only it's numeric number, which we do not need for the journal. So it is already very similar. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: Make the group that owns journal files configurable
On Thu, 07.03.13 17:38, Gergely Nagy (alger...@balabit.hu) wrote: I don't think this is really desirable. This group is something external packages should be able to make use of and rely on, and it would be suboptimal if you'd have to configure this group everywhere manually. The main reason behind the patch is that I already have systems installed where logfiles belong to a dedicated group, and when I'll be migrating those to systemd journal, I'd like to keep the groups and not introduce yet another one that does the same thing. There's already more groups on my systems than I need, I'd like to trim them down, not introduce new ones. Well, but there's no standard group so far that is only and exclusively used for log file access. There's adm, but that's rather losely defined only, and kinda suggests by its name it actually opens up more than just access to log files? I mean, we are not adding n or n^2 or 2^n or so groups here. We are adding just 1. Maybe the better idea is to get uucp and dip removed from the current set of default groups (at least we on Fedora still have these nonsensical groups...) So, I am very conservative on making this configurable, but hey, I can be convinced, so can you make a really good case for this? Apart from the case I outlined above, all other reasons I'd have boil down to convenience. Similarly how the 'tty' group's ID is configurable, the journal group being similarly configurable would make it much easier downstream to adapt the journal to an existing environment. Well, the tty group ID is very special. Normally we wouldn't care about the ID of the tty, but we require it very very early where NSS is not available to mount devpts. I mean, you are comparing apples and oranges here. Saying that there needs to be a group foo and saying that group foo must have ID 4711 is two very different things. We only do ther former, and make the latter configurable, because after all the entire user database exists in order to allow people to forget about the actual numer IDs assigned to the names. The group name is supposed to be an identifier, that helps people to know what things mean and by making this configruable you kinda break this point... I mean, if I have to add the users I have in the adm group to systemd-journal aswell, that means adding the group to LDAP, then updating the users too... ick. Too much work for no real gain for me. This is a misconception. The make install call will actually set an ACL on the journal dir, to grant adm and wheel read access to all journal files, existing and future. This is even documented in systemd-journald.service(8). We recommend all distributions to set up these ACLs the same way. So, to underline this: adm continues to have access to the journal files by default. systemd-journal is just an additional group, that happens to own the files, and that is more minimal than wheel, adm or any other group. Sorry, still not convinced... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: Make the group that owns journal files configurable
Kay Sievers k...@vrfy.org writes: On Thu, Mar 7, 2013 at 5:38 PM, Gergely Nagy alger...@balabit.hu wrote: Apart from the case I outlined above, all other reasons I'd have boil down to convenience. Similarly how the 'tty' group's ID is configurable, the journal group being similarly configurable would make it much easier downstream to adapt the journal to an existing environment. tty is also not configurable, only it's numeric number, which we do not need for the journal. So it is already very similar. :) No, because tty's gid (the only thing that is used, the tty group itself is never referenced, AFAICS) is configurable, while the journal group isn't. They *are* very similar in that the tty gid can vary between systems, and the group to access logs can too, and I'd like to keep using the existing group that I already have. (Which most often happens to be adm on most of my systems, so the former hardcoded value did not affect me. :P) Mind you, if the journal is changed to use a GID rather than a symbolic name, and make the gid configurable - that would be perfectly good for me too. -- |8] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fstab-generator: fsck /sysroot before we mount it rw
From: Harald Hoyer har...@redhat.com
---
src/fstab-generator/fstab-generator.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 910bbc1..b5fe0fa 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -449,6 +449,7 @@ static int parse_new_root_from_proc_cmdline(void) {
char *w, *state;
_cleanup_free_ char *what = NULL, *type = NULL, *opts = NULL, *line =
NULL;
int r;
+int fsck_passno = 0;
size_t l;
r = read_one_line_file(/proc/cmdline, line);
@@ -490,7 +491,16 @@ static int parse_new_root_from_proc_cmdline(void) {
if (!opts)
return log_oom();
-} else if (streq(word, ro) || streq(word, rw)) {
+} else if (streq(word, ro)) {
+fsck_passno = 0;
+tmp_word = opts;
+opts = strjoin(opts, ,, word, NULL);
+free(tmp_word);
+if (!opts)
+return log_oom();
+
+} else if (streq(word, rw)) {
+fsck_passno = 1;
tmp_word = opts;
opts = strjoin(opts, ,, word, NULL);
free(tmp_word);
@@ -513,7 +523,7 @@ static int parse_new_root_from_proc_cmdline(void) {
}
log_debug(Found entry what=%s where=/sysroot type=%s, what, type);
-r = add_mount(what, /sysroot, type, opts, 0, false, false, false,
+r = add_mount(what, /sysroot, type, opts, fsck_passno, false, false,
false,
false, false, /proc/cmdline);
return (r 0) ? r : 0;
--
1.8.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: Make the group that owns journal files configurable
Lennart Poettering lenn...@poettering.net writes: On Thu, 07.03.13 17:38, Gergely Nagy (alger...@balabit.hu) wrote: I don't think this is really desirable. This group is something external packages should be able to make use of and rely on, and it would be suboptimal if you'd have to configure this group everywhere manually. The main reason behind the patch is that I already have systems installed where logfiles belong to a dedicated group, and when I'll be migrating those to systemd journal, I'd like to keep the groups and not introduce yet another one that does the same thing. There's already more groups on my systems than I need, I'd like to trim them down, not introduce new ones. Well, but there's no standard group so far that is only and exclusively used for log file access. There's adm, but that's rather losely defined only, and kinda suggests by its name it actually opens up more than just access to log files? Yep, correct. And that is why the default of creating a separate group is a very good default. I mean, we are not adding n or n^2 or 2^n or so groups here. We are adding just 1. Maybe the better idea is to get uucp and dip removed from the current set of default groups (at least we on Fedora still have these nonsensical groups...) I already removed any group that is not used, dip and uucp included. My setup is *not* a default setup, hence my wish for a configurable group for journal files. The group name is supposed to be an identifier, that helps people to know what things mean and by making this configruable you kinda break this point... I don't see why it'd break that. Those who do not wish to change the group, nothing would change. I'm fairly sure that the vast majority of distributions wouldn't change it, either. So for, like 99% of the userbase, making it configurable would mean no change at all. But for that 1%, it'd be a tremendous help, even when 3rd party tools might break due to it. If I'd find any, I'd submit a patch there too. I mean, if I have to add the users I have in the adm group to systemd-journal aswell, that means adding the group to LDAP, then updating the users too... ick. Too much work for no real gain for me. This is a misconception. The make install call will actually set an ACL on the journal dir, to grant adm and wheel read access to all journal files, existing and future. This is even documented in systemd-journald.service(8). We recommend all distributions to set up these ACLs the same way. That still requires me to add the group, though, and merely offers a workaround. I'm not a fan of workarounds, neither a fan of additional groups that do nothing for me (as said, on the systems where the new group would be an issue, everyone who'd be in the journal's group if the ACLs weren't there, would be in adm too - so separating the two in this case is pointless). So, to underline this: adm continues to have access to the journal files by default. systemd-journal is just an additional group, that happens to own the files, and that is more minimal than wheel, adm or any other group. The additional part is the one that bothers me most. Sorry, still not convinced... No biggie, I'll continue patching systemd then until it gets very boring, and will see if I can come up with a better argument for the change at that point. -- |8] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: Make the group that owns journal files configurable
On Thu, Mar 7, 2013 at 6:07 PM, Gergely Nagy alger...@balabit.hu wrote: Kay Sievers k...@vrfy.org writes: On Thu, Mar 7, 2013 at 5:38 PM, Gergely Nagy alger...@balabit.hu wrote: Apart from the case I outlined above, all other reasons I'd have boil down to convenience. Similarly how the 'tty' group's ID is configurable, the journal group being similarly configurable would make it much easier downstream to adapt the journal to an existing environment. tty is also not configurable, only it's numeric number, which we do not need for the journal. So it is already very similar. :) No, because tty's gid (the only thing that is used, the tty group itself is never referenced, AFAICS) is configurable, while the journal group isn't. They *are* very similar in that the tty gid can vary between systems, and the group to access logs can too, and I'd like to keep using the existing group that I already have. (Which most often happens to be adm on most of my systems, so the former hardcoded value did not affect me. :P) Mind you, if the journal is changed to use a GID rather than a symbolic name, and make the gid configurable - that would be perfectly good for me too. tty is used all over udev, so it cannot be made configurable like you say. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] man: Unify title for configuration files
2013/3/7 Jan Janssen medhe...@web.de: --- man/hostname.xml | 2 +- man/localtime.xml | 2 +- man/machine-id.xml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/man/hostname.xml b/man/hostname.xml index 84a2961..f89332e 100644 --- a/man/hostname.xml +++ b/man/hostname.xml @@ -24,7 +24,7 @@ refentry id=hostname refentryinfo -title/etc/hostname/title +titlehostname/title I don't like this. Can we have the full path to the conf files in every man page instead, please. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] man: Unify title for configuration files
On Thu, Mar 07, 2013 at 06:40:29PM +0100, Michael Biebl wrote: 2013/3/7 Jan Janssen medhe...@web.de: --- man/hostname.xml | 2 +- man/localtime.xml | 2 +- man/machine-id.xml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/man/hostname.xml b/man/hostname.xml index 84a2961..f89332e 100644 --- a/man/hostname.xml +++ b/man/hostname.xml @@ -24,7 +24,7 @@ refentry id=hostname refentryinfo -title/etc/hostname/title +titlehostname/title I don't like this. Can we have the full path to the conf files in every man page instead, please. I think that this should be reverted. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] man: Unify title for configuration files
On Thu, 07.03.13 18:40, Michael Biebl (mbi...@gmail.com) wrote: 2013/3/7 Jan Janssen medhe...@web.de: --- man/hostname.xml | 2 +- man/localtime.xml | 2 +- man/machine-id.xml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/man/hostname.xml b/man/hostname.xml index 84a2961..f89332e 100644 --- a/man/hostname.xml +++ b/man/hostname.xml @@ -24,7 +24,7 @@ refentry id=hostname refentryinfo -title/etc/hostname/title +titlehostname/title I don't like this. Can we have the full path to the conf files in every man page instead, please. It's not as bad as this looks. It's still in there, in the SYNOPSIS... You barely notice the difference. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] bootchart: use _cleanup_fclose_
On Thu, Mar 7, 2013 at 7:10 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 07.03.13 08:52, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com Applied all three! Thanks! indeed! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [what-do-you-think? PATCH] man/*.html: link to directives and python in header
--- Results look like http://keszybz.github.com/systemd/. man/custom-html.xsl | 12 1 file changed, 12 insertions(+) diff --git a/man/custom-html.xsl b/man/custom-html.xsl index 906ddc5..a38c18d 100644 --- a/man/custom-html.xsl +++ b/man/custom-html.xsl @@ -40,6 +40,18 @@ xsl:textindex.html/xsl:text /xsl:attribute xsl:textIndex /xsl:text + /a· + a +xsl:attribute name=href + xsl:textsystemd.directives.html/xsl:text +/xsl:attribute +xsl:textDirectives /xsl:text + /a· + a +xsl:attribute name=href + xsl:textpython-systemd/index.html/xsl:text +/xsl:attribute +xsl:textPython /xsl:text /a hr/ /xsl:template -- 1.8.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] move mount_setup_early() to main.c
move mount_setup_early() call to main.c, before security module setup,
so there are no more repeat calls.
---
src/core/ima-setup.c | 5 -
src/core/main.c | 1 +
src/core/selinux-setup.c | 3 ---
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/core/ima-setup.c b/src/core/ima-setup.c
index e8cc1ba..7f8ec23 100644
--- a/src/core/ima-setup.c
+++ b/src/core/ima-setup.c
@@ -50,11 +50,6 @@ int ima_setup(void) {
int policyfd = -1, imafd = -1;
int result = 0;
-#ifndef HAVE_SELINUX
- /* Mount the securityfs filesystem */
- mount_setup_early();
-#endif
-
if (stat(IMA_POLICY_PATH, st) 0)
return 0;
diff --git a/src/core/main.c b/src/core/main.c
index 2bbea7e..c4a3075 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1346,6 +1346,7 @@ int main(int argc, char *argv[]) {
}
if (!skip_setup) {
+mount_setup_early();
if (selinux_setup(loaded_policy) 0)
goto finish;
if (ima_setup() 0)
diff --git a/src/core/selinux-setup.c b/src/core/selinux-setup.c
index e9c0de9..0723d7c 100644
--- a/src/core/selinux-setup.c
+++ b/src/core/selinux-setup.c
@@ -58,9 +58,6 @@ int selinux_setup(bool *loaded_policy) {
cb.func_log = null_log;
selinux_set_callback(SELINUX_CB_LOG, cb);
- /* Make sure getcon() works, which needs /proc and /sys */
- mount_setup_early();
-
/* Already initialized by somebody else? */
r = getcon_raw(con);
if (r == 0) {
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] mount and initialize Smack
SMACK is the Simple Mandatory Access Control Kernel, a minimal
approach to Access Control implemented as a kernel LSM.
The kernel exposes the smackfs filesystem API through which access
rules can be loaded. At boot time, we want to load the access rules
as early as possible to ensure all early boot steps are checked by Smack.
This patch mounts smackfs at the new location at /sys/fs/smackfs for
kernels 3.8 and above. The /smack mountpoint is not supported.
After mounting smackfs, rules are loaded from the usual location.
For more information about Smack see:
http://www.kernel.org/doc/Documentation/security/Smack.txt
---
Makefile.am| 2 ++
README | 2 ++
src/core/main.c| 3 ++
src/core/mount-setup.c | 4 ++-
src/core/smack-setup.c | 93 ++
src/core/smack-setup.h | 26 ++
6 files changed, 129 insertions(+), 1 deletion(-)
create mode 100644 src/core/smack-setup.c
create mode 100644 src/core/smack-setup.h
diff --git a/Makefile.am b/Makefile.am
index 7e40879..3f64937 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -842,6 +842,8 @@ libsystemd_core_la_SOURCES = \
src/core/selinux-access.h \
src/core/selinux-setup.c \
src/core/selinux-setup.h \
+ src/core/smack-setup.c \
+ src/core/smack-setup.h \
src/core/ima-setup.c \
src/core/ima-setup.h \
src/core/locale-setup.h \
diff --git a/README b/README
index 5649a51..6a70b47 100644
--- a/README
+++ b/README
@@ -44,6 +44,8 @@ REQUIREMENTS:
CONFIG_NET
CONFIG_SYSFS
+ Linux kernel = 3.8 for Smack support
+
Udev will fail to work with the legacy layout:
CONFIG_SYSFS_DEPRECATED=n
diff --git a/src/core/main.c b/src/core/main.c
index c4a3075..b7f7faa 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -67,6 +67,7 @@
#include selinux-setup.h
#include ima-setup.h
#include fileio.h
+#include smack-setup.h
static enum {
ACTION_RUN,
@@ -1351,6 +1352,8 @@ int main(int argc, char *argv[]) {
goto finish;
if (ima_setup() 0)
goto finish;
+if (smack_setup() 0)
+goto finish;
}
if (label_init(NULL) 0)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index dab3601..42cdc6d 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -66,7 +66,7 @@ typedef struct MountPoint {
/* The first three entries we might need before SELinux is up. The
* fourth (securityfs) is needed by IMA to load a custom policy. The
* other ones we can delay until SELinux and IMA are loaded. */
-#define N_EARLY_MOUNT 4
+#define N_EARLY_MOUNT 5
static const MountPoint mount_table[] = {
{ proc, /proc, proc, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
@@ -77,6 +77,8 @@ static const MountPoint mount_table[] = {
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ securityfs, /sys/kernel/security, securityfs, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
NULL, MNT_NONE },
+{ smackfs,/sys/fs/smackfs, smackfs,
smackfsdef=*, MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
+ NULL, MNT_NONE },
{ tmpfs, /dev/shm, tmpfs,
mode=1777, MS_NOSUID|MS_NODEV|MS_STRICTATIME,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ devpts, /dev/pts, devpts,
mode=620,gid= STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC,
diff --git a/src/core/smack-setup.c b/src/core/smack-setup.c
new file mode 100644
index 000..7577ecd
--- /dev/null
+++ b/src/core/smack-setup.c
@@ -0,0 +1,93 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+ This file is part of systemd.
+
+ Copyright (C) 2013 Intel Corporation
+ Authors:
+Nathaniel Chen nathaniel.c...@intel.com
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published
+ by the Free Software Foundation; either version 2.1 of the License,
+ or (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include stdio.h
+#include errno.h
+#include string.h
+#include unistd.h
+#include stdlib.h
+#include sys/vfs.h
+#include fcntl.h
+#include sys/types.h
+#include dirent.h
+#include sys/mount.h
+#include stdint.h
+
+#include macro.h
+#include smack-setup.h
+#include util.h
+#include log.h
+#include label.h
+
+#define
[systemd-devel] [PATCH] bootchart: use _cleanup_close_
use _cleanup_{close_,fclose_} to close streams and file descriptors
---
src/bootchart/bootchart.c | 8 +++-
src/bootchart/svg.c | 5 +
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index 65f16c5..0ad14dc 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -66,10 +66,10 @@ struct cpu_stat_struct cpustat[MAXCPUS];
int pscount;
int cpus;
double interval;
-FILE *of = NULL;
+FILE _cleanup_fclose_ *of = NULL;
int overrun = 0;
static int exiting = 0;
-int sysfd=-1;
+int _cleanup_close_ sysfd=-1;
/* graph defaults */
bool entropy = false;
@@ -106,7 +106,7 @@ int main(int argc, char *argv[])
char datestr[200];
time_t t = 0;
const char *fn;
-_cleanup_fclose_ FILE *f;
+_cleanup_fclose_ FILE *f = NULL;
int gind;
int i, r;
char *init = NULL, *output = NULL;
@@ -378,10 +378,8 @@ int main(int argc, char *argv[])
svg_do(build);
fprintf(stderr, systemd-bootchart wrote %s\n, output_file);
-fclose(of);
closedir(proc);
-close(sysfd);
/* nitpic cleanups */
ps = ps_first;
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index 9fee810..7947671 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -150,7 +150,7 @@ static void svg_title(const char *build)
char date[256] = Unknown;
char cpu[256] = Unknown;
char *c;
-FILE *f;
+FILE _cleanup_fclose_ *f = NULL;
time_t t;
int fd;
struct utsname uts;
@@ -161,7 +161,6 @@ static void svg_title(const char *build)
if (f) {
if (!fgets(cmdline, 255, f))
sprintf(cmdline, Unknown);
-fclose(f);
}
/* extract root fs so we can find disk model name in sysfs */
@@ -176,7 +175,6 @@ static void svg_title(const char *build)
if (f) {
if (!fgets(model, 255, f))
fprintf(stderr, Error reading disk model for
%s\n, rootbdev);
-fclose(f);
}
}
@@ -198,7 +196,6 @@ static void svg_title(const char *build)
break;
}
}
-fclose(f);
}
svg(text class=\t1\ x=\0\ y=\30\Bootchart for %s -
%s/text\n,
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [what-do-you-think? PATCH] man/*.html: link to directives and python in header
On Thu, 07.03.13 13:25, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: --- Results look like http://keszybz.github.com/systemd/. Love it! man/custom-html.xsl | 12 1 file changed, 12 insertions(+) diff --git a/man/custom-html.xsl b/man/custom-html.xsl index 906ddc5..a38c18d 100644 --- a/man/custom-html.xsl +++ b/man/custom-html.xsl @@ -40,6 +40,18 @@ xsl:textindex.html/xsl:text /xsl:attribute xsl:textIndex /xsl:text + /a· + a +xsl:attribute name=href + xsl:textsystemd.directives.html/xsl:text +/xsl:attribute +xsl:textDirectives /xsl:text + /a· + a +xsl:attribute name=href + xsl:textpython-systemd/index.html/xsl:text +/xsl:attribute +xsl:textPython /xsl:text /a hr/ /xsl:template Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [what-do-you-think? PATCH] man/*.html: link to directives and python in header
On Thu, Mar 7, 2013 at 11:28 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 07.03.13 13:25, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: --- Results look like http://keszybz.github.com/systemd/. Love it! totally! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [what-do-you-think? PATCH] man/*.html: link to directives and python in header
2013/3/7 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: --- Results look like http://keszybz.github.com/systemd/. Getting 404 for stuff like http://keszybz.github.com/systemd/SD_JOURNAL_INVALIDATE.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] mount and initialize Smack
On Thu, 07.03.13 11:06, Nathaniel Chen (nathaniel.c...@intel.com) wrote:
SMACK is the Simple Mandatory Access Control Kernel, a minimal
approach to Access Control implemented as a kernel LSM.
The kernel exposes the smackfs filesystem API through which access
rules can be loaded. At boot time, we want to load the access rules
as early as possible to ensure all early boot steps are checked by Smack.
This patch mounts smackfs at the new location at /sys/fs/smackfs for
kernels 3.8 and above. The /smack mountpoint is not supported.
After mounting smackfs, rules are loaded from the usual location.
For more information about Smack see:
http://www.kernel.org/doc/Documentation/security/Smack.txt
Merged all three, but made some changes. Just to point this out:
+int smack_setup(void) {
+
+FILE _cleanup_fclose_ *smack = NULL;
+FILE _cleanup_fclose_ *policy = NULL;
+int _cleanup_close_ dfd = -1;
+int _cleanup_close_ pol = -1;
The _cleanup_xyz_ stuff works on the C block scope. i.e. if you use this
like this these the four variables will be freed once when the function
exits. However, you allocate into them a couple of times inside the
inner loop, so the earlier instances are lost. Moving this into the loop
instead fixes it, since then the per-scope logic makes sure the
variables are freed on each loop iteration.
Also, the diretcory fd is closed as part of the DIR* object anyway, and
similar the pol fd is closed as part of the policy FILE* object. So you
closed these twice.
+DIR *dir = NULL;
+struct dirent *entry;
+char buf[NAME_MAX];
+
+smack = fopen(/sys/fs/smackfs/load2, we);
+if (smack == NULL) {
+log_info(Smack is not enabled in the kernel, not loading
access rules.);
+return 0;
+}
+
+/* write rules to load2 from every file in the directory */
+dir = opendir(ACCESSES_D_PATH);
+if (dir == NULL) {
+log_info(Smack access rules directory not found: %s,
ACCESSES_D_PATH);
+return 0;
+}
+dfd = dirfd(dir);
+if (dfd == -1) {
+log_error(Smack access rules directory %s not opened: %m.,
ACCESSES_D_PATH);
+return 0;
+}
+FOREACH_DIRENT(entry, dir, return 0;) {
+if (entry-d_name[0] == '.')
+continue;
This is actually redundant, as the macro does it anyway...
+pol = openat(dfd, entry-d_name, O_RDONLY);
+if (pol == -1) {
+log_error(Smack access rule file %s not opened:
%m, entry-d_name);
+continue;
+}
+policy = fdopen(pol, re);
+if (policy == NULL) {
+log_error(Smack access rule file %s not opened:
%m, entry-d_name);
+continue;
+}
+/* load2 write rules in the kernel require a line buffered
stream */
+FOREACH_LINE(buf, policy, log_error(Failed to read
from Smack access rule file %s: %m, policy); continue;) {
You certainly don't want to continue reading file after we hit an IO
error... That would result in a busy loop.
+fputs(buf, smack);
+fflush(smack);
+}
+}
+log_info(Successfully loaded Smack policies.);
Anyway, all commited, but not tested after my changes, since I don't
have SMACK. Please test.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC PATCH] journalctl: downgrade access check error to a warning
There are many ways in which we can get those checks wrong,
so it is better to warn and then error out on a real access
failure.
---
What about downgrading the warnings to avoid bug reports when
the check is wrong?
src/journal/journalctl.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 3682329..6118fb0 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -878,24 +878,21 @@ static int verify(sd_journal *j) {
return r;
}
-static int access_check(void) {
-
+static void access_warning(void) {
#ifdef HAVE_ACL
-if (access(/var/log/journal, F_OK) 0 geteuid() != 0
in_group(systemd-journal) = 0) {
-log_error(Unprivileged users can't see messages unless
persistent log storage is enabled. Users in the group 'systemd-journal' can
always see messages.);
-return -EACCES;
-}
-
-if (!arg_quiet geteuid() != 0 in_group(systemd-journal) = 0)
-log_warning(Showing user generated messages only. Users in
the group 'systemd-journal' can see all messages. Pass -q to turn this notice
off.);
+if (access(/var/log/journal, F_OK) 0
+geteuid() != 0
+in_group(systemd-journal) = 0)
+log_warning(Unprivileged users can't see messages unless
persistent log storage is enabled.
+Users in the group 'systemd-journal' can always
see messages.);
+else if (!arg_quiet geteuid() != 0
+ in_group(systemd-journal) = 0)
+log_warning(Showing user generated messages only. Users in
the group 'systemd-journal' can
+see all messages. Pass -q to turn this notice
off.);
#else
-if (geteuid() != 0 in_group(systemd-journal) = 0) {
-log_error(No access to messages. Only users in the group
'systemd-journal' can see messages.);
-return -EACCES;
-}
+if (geteuid() != 0 in_group(systemd-journal) = 0)
+log_warning(No access to messages. Only users in the group
'systemd-journal' can see messages.);
#endif
-
-return 0;
}
int main(int argc, char *argv[]) {
@@ -938,9 +935,7 @@ int main(int argc, char *argv[]) {
goto finish;
}
-r = access_check();
-if (r 0)
-goto finish;
+access_warning();
if (arg_directory)
r = sd_journal_open_directory(j, arg_directory, 0);
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [what-do-you-think? PATCH] man/*.html: link to directives and python in header
On Thu, Mar 07, 2013 at 08:42:22PM +0100, Michael Biebl wrote: 2013/3/7 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: --- Results look like http://keszybz.github.com/systemd/. Getting 404 for stuff like http://keszybz.github.com/systemd/SD_JOURNAL_INVALIDATE.html Seems that those .html files are not generated. Will investigate. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: Make the group that owns journal files configurable
Kay Sievers k...@vrfy.org writes: tty is used all over udev, so it cannot be made configurable like you say. I never asked to change tty in any way. I brought it up as something that shows some resemblance to the journal group, which I did want to make configurable. Nothing more. But no matter, I'll just patch locally for now. -- |8] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 198
Hey! Finally, here's 198, with many big changes: http://www.freedesktop.org/software/systemd/systemd-198.tar.xz In detail: * Configuration of unit files may now be extended via drop-in files without having to edit/override the unit files themselves. More specifically, if the administrator wants to change one value for a service file foobar.service he can now do so by dropping in a configuration snippet into /etc/systemd/systemd/foobar.service.d/*.conf. The unit logic will load all these snippets and apply them on top of the main unit configuration file, possibly extending or overriding its settings. Using these drop-in snippets is generally nicer than the two earlier options for changing unit files locally: copying the files from /usr/lib/systemd/system/ to /etc/systemd/system/ and editing them there; or creating a new file in /etc/systemd/system/ that incorporates the original one via .include. Drop-in snippets into these .d/ directories can be placed in any directory systemd looks for units in, and the usual overriding semantics between /usr/lib, /etc and /run apply for them too. * Most unit file settings which take lists of items can now be reset by assigning the empty string to them. For example, normally, settings such as Environment=FOO=BAR append a new environment variable assignment to the environment block, each time they are used. By assigning Environment= the empty string the environment block can be reset to empty. This is particularly useful with the .d/*.conf drop-in snippets mentioned above, since this adds the ability to reset list settings from vendor unit files via these drop-ins. * systemctl gained a new list-dependencies command for listing the dependencies of a unit recursively. * Inhibitors are now honored and listed by systemctl suspend, systemctl poweroff (and similar) too, not only GNOME. These commands will also list active sessions by other users. * Resource limits (as exposed by the various control group controllers) can now be controlled dynamically at runtime for all units. More specifically, you can now use a command like systemctl set-cgroup-attr foobar.service cpu.shares 2000 to alter the CPU shares a specific service gets. These settings are stored persistently on disk, and thus allow the administrator to easily adjust the resource usage of services with a few simple commands. This dynamic resource management logic is also available to other programs via the bus. Almost any kernel cgroup attribute and controller is supported. * systemd-vconsole-setup will now copy all font settings to all allocated VTs, where it previously applied them only to the foreground VT. * libsystemd-login gained the new sd_session_get_tty() API call. * This release drops support for a few legacy or distribution-specific LSB facility names when parsing init scripts: $x-display-manager, $mail-transfer-agent, $mail-transport-agent, $mail-transfer-agent, $smtp, $null. Also, the mail-transfer-agent.target unit backing this has been removed. Distributions which want to retain compatibility with this should carry the burden for supporting this themselves and patch support for these back in, if they really need to. Also, the facilities $syslog and $local_fs are now ignored, since systemd does not support early-boot LSB init scripts anymore, and these facilities are implied anyway for normal services. syslog.target has also been removed. * There are new bus calls on PID1's Manager object for cancelling jobs, and removing snapshot units. Previously, both calls were only available on the Job and Snapshot objects themselves. * systemd-journal-gatewayd gained SSL support. * The various environment files, such as /etc/locale.conf now support continuation lines with a backslash (\) as last character in the line, similar in style (but different) to how this is supported in shells. * For normal user processes the _SYSTEMD_USER_UNIT= field is now implicitly appended to every log entry logged. systemctl has been updated to filter by this field when operating on a user systemd instance. * nspawn will now implicitly add the CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL capabilities to the capabilities set for the container. This makes it easier to boot unmodified
[systemd-devel] html pages for aliases
Hi, Michael Biebl pointed out that some links in www.freedesktop.org/software/systemd/man/index.html are broken. Unfortunately all links to man page aliases are broken. This is because only man includes are generated (e.g. build/man/init.1 contains only '.so man1/systemd.1'). There are a few options how to deal with this problem: 1. modify generation logic to link to the target page directly, not the alias 2. add stub HTML pages which contain a redirect (probably both meta http-equiv=refresh content= and javascript and an explicit link to be safe). 3. add server redirects in a .htaccess file. .htaccess would be generated along with the index. I don't like option 1. because it break the property that one can go to www.freedesktop.org/software/systemd/man/xxx.html and see the man page for xxx. Option 3. would be nicest but would require allowing .htaccess on fd.o, which is currently not allowed. Option 2. would work too. Thoughts, solutions, comments? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 198
Hi, Nice to see that... seems it was time for a release... ;-) a few questions in line: - Original Message - Hey! Finally, here's 198, with many big changes: * Resource limits (as exposed by the various control group controllers) can now be controlled dynamically at runtime for all units. More specifically, you can now use a command like systemctl set-cgroup-attr foobar.service cpu.shares 2000 to alter the CPU shares a specific service gets. These settings are stored persistently on disk, and thus allow the administrator to easily adjust the resource usage of services with a few simple commands. This dynamic resource management logic is also available to other programs via the bus. Almost any kernel cgroup attribute and controller is supported. Can you explain how the settings for a particular units are persistently stored. Does systemd write back such values into the particular unit, or are they stored somewhere else? The reason why I'm asking is the facts that stuff like this strives the configuration management functions of a Linux system. The question would be: How many configuration management should go into units? just bootstrapping or also runtime changes or even runtime changes which going to be stored persistently afterwards? the later comes close to the MacOS defaults write command I think. http://ss64.com/osx/defaults.html * The Python API of systemd now gained a new module for reading journal files. Are the problems with jumping to the end of the journal fixed? -- Holger Winkelmann email: h...@travelping.com mobil: +49-171-5594745 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] core: keep mountinfo .mounts until late shutdown
Hi, This will be my first priority to either provide more information or open a bug as soon as I have time but I remember trying all the logical thoughts you are mentioning and they didn't work. I had to have both BEFORE and REQUIRED_BY dependency. Now that 198 is out, I will give it a shot again on it. Sorry for the delay. Thanks On Mon, Mar 4, 2013 at 8:30 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Feb 14, 2013 at 09:15:28PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Feb 04, 2013 at 05:27:24PM +0100, Umut Tezduyar wrote: Hi On Mon, Feb 4, 2013 at 4:23 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Hi, On Mon, Feb 04, 2013 at 03:03:59PM +0100, Umut Tezduyar wrote: Downside of this patch is, mountinfo mounts stick around as inactive-dead even when the file system they represent is unmounted. On Mon, Feb 4, 2013 at 3:00 PM, Umut Tezduyar u...@tezduyar.com wrote: .mount units coming from /proc/self/mountinfo file are unmounted after local-fs.target is reached during shutdown. Problem: .mount units popping up in mountinfo file are added to systemd without any dependency. For that reason, Hm, what do you mean exactly by that? Mount units I see have dependencies on mount points higher in the hierarchy. E.g. Requires=systemd-journald.socket -.mount home.mount After=systemd-journald.socket -.mount home.mount Description=/home/zbyszek/debian-x32/home SourcePath=/proc/self/mountinfo Mount units have dependencies on higher mount points but they do not have default dependencies like local-fs-pre.target, local-fs.target, umount.target. You can compare a mount unit coming from /etc/fstab with one /proc/self/mountinfo. Hi, I think that an addition of relationships with other units is necessary. But adding RequiredBy=local-fs.target,Before=local-fs.target doesn't seem to be the right combination. Before=local-fs.target - OK. RequiredBy=local-fs.target - This one doesn't seem to be necessary. In practice there's little difference since alread-mounted mounts can't fail, but it's better to keep the dependency graph sparse. Conflicts=umount.target - I think that we want this one. Without this, mounts added by hand will be left till the very end, but there's no reason to make them special like this. Ping? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [what-do-you-think? PATCH] man/*.html: link to directives and python in header
GREAT! One suggestion though, would it make sense to split the APIs from programs? Currently, S index is filled with APIs that most of the users only scroll. On Thu, Mar 7, 2013 at 7:25 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: --- Results look like http://keszybz.github.com/systemd/. man/custom-html.xsl | 12 1 file changed, 12 insertions(+) diff --git a/man/custom-html.xsl b/man/custom-html.xsl index 906ddc5..a38c18d 100644 --- a/man/custom-html.xsl +++ b/man/custom-html.xsl @@ -40,6 +40,18 @@ xsl:textindex.html/xsl:text /xsl:attribute xsl:textIndex /xsl:text + /a· + a +xsl:attribute name=href + xsl:textsystemd.directives.html/xsl:text +/xsl:attribute +xsl:textDirectives /xsl:text + /a· + a +xsl:attribute name=href + xsl:textpython-systemd/index.html/xsl:text +/xsl:attribute +xsl:textPython /xsl:text /a hr/ /xsl:template -- 1.8.1.4 ___ 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
