[systemd-devel] [PATCH 2/2] tmpfiles: explicitly check for existing files
On read-only filesystems trying to create the target will not fail with
EEXIST but with EROFS.
---
Some more cases that fail on read-only filesystems.
src/tmpfiles/tmpfiles.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 3bab7ac..3572367 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -671,7 +671,10 @@ static int create_item(Item *i) {
break;
case COPY_FILES:
-r = copy_tree(i-argument, i-path, false);
+if (stat(i-path, st) 0)
+r = copy_tree(i-argument, i-path, false);
+else
+r = -EEXIST;
if (r 0) {
struct stat a, b;
@@ -789,13 +792,17 @@ static int create_item(Item *i) {
case CREATE_SYMLINK:
label_context_set(i-path, S_IFLNK);
-r = symlink(i-argument, i-path);
+if (stat(i-path, st) 0) {
+if (symlink(i-argument, i-path) 0)
+r = -errno;
+} else
+r = -EEXIST;
label_context_clear();
if (r 0) {
_cleanup_free_ char *x = NULL;
-if (errno != EEXIST) {
+if (r != -EEXIST) {
log_error(symlink(%s, %s) failed: %m,
i-argument, i-path);
return -errno;
}
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2 1/2] tmpfiles: only execute chmod()/chown() when needed
This avoids errors like this, when the paths are already there with the
correct permissions and owner:
chmod(/var/spool) failed: Read-only file system
---
Changes since v1:
- remember if stat() was successful and use it everywhere.
The original code checked for 'stat() = 0'. Any reason for that? My
man-page says 'On success, zero is returned'.
src/tmpfiles/tmpfiles.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 79fd0b7..3bab7ac 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -453,35 +453,39 @@ finish:
}
static int item_set_perms(Item *i, const char *path) {
+struct stat st;
+bool st_valid;
+
assert(i);
assert(path);
+st_valid = stat(path, st) == 0;
+
/* not using i-path directly because it may be a glob */
if (i-mode_set) {
mode_t m = i-mode;
-if (i-mask_perms) {
-struct stat st;
-
-if (stat(path, st) = 0) {
-if (!(st.st_mode 0111))
-m = ~0111;
-if (!(st.st_mode 0222))
-m = ~0222;
-if (!(st.st_mode 0444))
-m = ~0444;
-if (!S_ISDIR(st.st_mode))
-m = ~07000; /* remove
sticky/sgid/suid bit, unless directory */
-}
+if (i-mask_perms st_valid) {
+if (!(st.st_mode 0111))
+m = ~0111;
+if (!(st.st_mode 0222))
+m = ~0222;
+if (!(st.st_mode 0444))
+m = ~0444;
+if (!S_ISDIR(st.st_mode))
+m = ~07000; /* remove sticky/sgid/suid bit,
unless directory */
}
-if (chmod(path, m) 0) {
-log_error(chmod(%s) failed: %m, path);
-return -errno;
+if (!st_valid || m != (st.st_mode 0)) {
+if (chmod(path, m) 0) {
+log_error(chmod(%s) failed: %m, path);
+return -errno;
+}
}
}
-if (i-uid_set || i-gid_set)
+if ((!st_valid || (i-uid != st.st_uid || i-gid != st.st_gid))
+(i-uid_set || i-gid_set))
if (chown(path,
i-uid_set ? i-uid : (uid_t) -1,
i-gid_set ? i-gid : (gid_t) -1) 0) {
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Build errors with lto and compat-libs
Hi, With --enable-compat-libs building fails like this: CCLD libsystemd-journal.la [...] /tmp/ccISOiYU.ltrans1.ltrans.o: In function `sd_journal_process': ccISOiYU.ltrans1.o:(.text+0x0): multiple definition of `sd_journal_process' libsystemd_journal_internal_la-sd-journal.o (symbol from plugin):(.text+0x0): first defined here [...] for all symbols listed in src/compat-libs/libsystemd-journal.sym I have no idea what happens here, but making 'obsolete_lib()' a noop or removing lto from configure.ac 'fixes' the problem. This is with gcc-4.8.2 and binutils-2.24 building for ARM. Any ideas what happens here? 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
Re: [systemd-devel] [aur-requests] [PRQ#512] Request Accepted
On Sunday 17 August 2014 at 11:18:25, Martti Kühne wrote: On Sun, Aug 17, 2014 at 7:39 AM, carstene1ns a...@carsten-teibes.de wrote: Package maintainer was a TU and he even re-uploaded the package now. Who is at fault here? FredBezies for requesting? foutrelis for deleting? keenerd for maintaining and re-uploading? just to bring it up: ...or google for threading all request accepted and request declined emails. can't we use the same subject (thread-id?) as the respective request? that would provide a more sensible grouping in whatever email browser you're using... cheers! mar77i The In-Reply-To: header seems to be correctly set on automated emails. Apparently it's gmail web interface to blame. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PGP replacement?
So http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html makes the point that pgp is old school and should be taken to the pasture to die. Like upstart and inetd I take. Is there a replacement built into systemd? If not, I would like to suggest that as something to be integrated into it that would learn from the mistakes of pgp. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Friday 15 August 2014 at 15:35:06, Ivan Shapovalov wrote: [...] Ah, right. This is actually correct here. We want to make sure that the root fs is remounted before we mount the other units, since this might required creating additional directories to mount things on... There are two more complications: a) if you want to make use of local-fs-pre.target you actually have to pull it in, it's a passive unit. See systemd.special(5). b) You want to run your stuff before fsck is run on the devices, so that you don't end up interrupting an fsck that is half in progress. To put this together, in your unit file you need: Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service Wants=local-fs-pre.target That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). Lennart One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. This can be solved by introducing two resume units (say, systemd-resume@.service and initrd-resume@.service), first with Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service Wants=local-fs-pre.target ConditionPathIsReadWrite=!/ and the second one with ConditionPathExists=/etc/initrd-release # something else ? BTW... are you sure that the second variant (in initramfs) does not require something to order before sysroot.mount and all fsck units?.. Actually, in case of initramfs these dependencies are not enough. In case of initramfs, there is no apparent way to order before all mounts and their fsck instances, especially given that there are no equivalents of systemd-remount-fs.service and systemd-fsck-root.service. Or do I miss something? Could you (someone) please give an advice? I'm also uncertain whether having two units (for initramfs and for real root) is the only way. Thanks, -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PGP replacement?
On Sun, Aug 17, 2014 at 08:35:00AM -0400, Mauricio Tavares wrote: So http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html makes the point that pgp is old school and should be taken to the pasture to die. Like upstart and inetd I take. Is there a replacement built into systemd? If not, I would like to suggest that as something to be integrated into it that would learn from the mistakes of pgp. As PGP stuff has completely nothing to do with basic Linux platform, your post seem to be obvious trolling. Please do not do that. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] seat1 ACL
Hey, maybe I'm missing something, but a user on the second seat (seat1) does not get the right rights from logind. $ udevadm info /dev/snd/controlC2 P: /devices/pci:00/:00:1e.0/:08:02.0/sound/card2/controlC2 N: snd/controlC2 S: snd/by-path/pci-:08:02.0 E: DEVLINKS=/dev/snd/by-path/pci-:08:02.0 E: DEVNAME=/dev/snd/controlC2 E: DEVPATH=/devices/pci:00/:00:1e.0/:08:02.0/sound/card2/controlC2 E: ID_PATH=pci-:08:02.0 E: ID_PATH_TAG=pci-_08_02_0 E: ID_SEAT=seat1 E: MAJOR=116 E: MINOR=17 E: SUBSYSTEM=sound E: TAGS=:seat1:uaccess: E: USEC_INITIALIZED=70638 $ getfacl /dev/snd/controlC2 # file: dev/snd/controlC2 # owner: root # group: audio user::rw- user:Debian-gdm:rw- group::rw- mask::rw- other::--- A user logs in on seat1, but the user:Debian-gdm line is removed, instead of changed. $ getfacl /dev/snd/controlC2 # file: dev/snd/controlC2 # owner: root # group: audio user::rw- group::rw- mask::rw- other::--- On seat0 I get the expected user:floris:rw- line $ getfacl /dev/snd/controlC3 # file: dev/snd/controlC3 # owner: root # group: audio user::rw- user:floris:rw- group::rw- mask::rw- other::--- Do I miss a package or is this a bug? Thanks, floris $ systemd --version systemd 208 +PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PGP replacement?
On Aug 17, 2014 1:33 PM, Tomasz Torcz to...@pipebreaker.pl wrote: On Sun, Aug 17, 2014 at 08:35:00AM -0400, Mauricio Tavares wrote: So http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html makes the point that pgp is old school and should be taken to the pasture to die. Like upstart and inetd I take. Is there a replacement built into systemd? If not, I would like to suggest that as something to be integrated into it that would learn from the mistakes of pgp. As PGP stuff has completely nothing to do with basic Linux platform, your post seem to be obvious trolling. Please do not do that. I was thinking on secure event reporting, maybe with firewalld or even earlier. I was not aware that is obviously trolling, so I do apologize and will say no more on the subject. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML ___ 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
[systemd-devel] [RFC] Integrate export mount command in code
Good time of day, i just want to ask: Systemd depend on util-linux mount command and in code we call him, may have a sense to import and cleanup code to systemd base, and just call function in systemd, instead of using mount command? But only benefit what i see: it faster, when call external command, but i can miss something -- Have a nice day, Timofey. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Integrate export mount command in code
On Mon, Aug 18, 2014 at 12:25:00AM +0300, Timofey Titovets wrote: Good time of day, i just want to ask: Systemd depend on util-linux mount command and in code we call him, may have a sense to import and cleanup code to systemd base, and just call function in systemd, instead of using mount command? But only benefit what i see: it faster, when call external command, but i can miss something tl;dr: this simply isn't a good idea, as it would require reimplementing a substantial amount of code to retain feature parity. systemd already uses mount(2) where it's reasonable: kernel filesystems like /sys, /dev, and /proc. Some reasons not to do this for all filesystems: 1) You have to fork, anyways, because you don't want to call mount(2) from PID 1 -- the syscall may not return for a relatively long period of time. During this time, systemd will be entirely non-responsive. 2) Mounting filesystems is sometimes complex, and involves an external helper, regardless. fuse, cifs, and nfs immediately come to mind, but there's others. mount(8) knows how to find and execute these when necessary. 3) mount(8) takes care of cleaning the option string from /etc/fstab -- not all options are meant to be passed to the kernel (or the external mount helpers), such as any option which starts with x- (like x-systemd.automount). Cheers, d ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Integrate export mount command in code
Thanks for explanation, it thread can be closed. 2014-08-18 0:41 GMT+03:00 Dave Reisner d...@falconindy.com: On Mon, Aug 18, 2014 at 12:25:00AM +0300, Timofey Titovets wrote: Good time of day, i just want to ask: Systemd depend on util-linux mount command and in code we call him, may have a sense to import and cleanup code to systemd base, and just call function in systemd, instead of using mount command? But only benefit what i see: it faster, when call external command, but i can miss something tl;dr: this simply isn't a good idea, as it would require reimplementing a substantial amount of code to retain feature parity. systemd already uses mount(2) where it's reasonable: kernel filesystems like /sys, /dev, and /proc. Some reasons not to do this for all filesystems: 1) You have to fork, anyways, because you don't want to call mount(2) from PID 1 -- the syscall may not return for a relatively long period of time. During this time, systemd will be entirely non-responsive. 2) Mounting filesystems is sometimes complex, and involves an external helper, regardless. fuse, cifs, and nfs immediately come to mind, but there's others. mount(8) knows how to find and execute these when necessary. 3) mount(8) takes care of cleaning the option string from /etc/fstab -- not all options are meant to be passed to the kernel (or the external mount helpers), such as any option which starts with x- (like x-systemd.automount). Cheers, d -- Have a nice day, Timofey. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
