[systemd-devel] [PATCH 2/4] Allow systemd-tmpfiles to set the file/directory attributes

[Lennart Poettering]

On Mon, 13.04.15 11:31, Lennart Poettering (lennart at poettering.net) wrote:

> On Sun, 12.04.15 22:19, Goffredo Baroncelli (kreijack at libero.it) wrote:
> 
> > However the original code catch also the case where the file is a soft-link.
> > The same check is performed also by chattr(1); I suggest to leave the original
> > behavior, changing
> > 
> >         fd = open(path, O_RDONLY|O_NONBLOCK|O_CLOEXEC);
> > in
> > 	fd = open(path, O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_NOFOLLOW);
> > 
> > and checking if the errno is ELOOP. In this case a further check is performed to 
> > verify if the file is a link or the error is due to a too many symbolic link.
> > Then an appropriate message error is printed.
> > 
> > What do you think ?
> 
> We should probably either follow symlinks for all of tmpfiles'
> operations or for none. 
> 
> While I generally believe that we probably shouldn't follow symlinks,
> it's really difficult to implement given that fchmodat() currenlty
> doesn't work with AT_SYMLINK_FOLLOW (according to the man page at
> least), and acl_set_file doesn't allow not following symlinks either... :-(
> 
> Hmm, I can't say I like this I must say.
> 
> ideas?

I now fixed much of the code to not follow symlinks anymore. With a
combination of O_PATH and using /proc/self/fd/%i for acl_set_file() I
managed to get all of the xattr, acl, file attribute, chmod, chown
code to not follow symlinks anymore.

I also documented this behaviour in the man page for the lines where
this applies.

I am pretty sure we should not follow symlinks when creating new file
objects or adjusting existing ones (with the notable exception of "w"
lines). Right now we still follow symlinks when creating dirs, fifos,
device nodes. We should fix that too.

Anyway, Goffredo, the file attribute code will not follow symlinks
anymore, hence this should settle this issue you raised.

Lennart

-- 
Lennart Poettering, Red Hat