linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] xfs_scrub: don't set WorkingDirectory= in systemd job
@ 2020-04-14 15:43 Darrick J. Wong
  2020-04-14 16:40 ` Eric Sandeen
  0 siblings, 1 reply; 2+ messages in thread
From: Darrick J. Wong @ 2020-04-14 15:43 UTC (permalink / raw)
  To: Eric Sandeen; +Cc: xfs

From: Darrick J. Wong <darrick.wong@oracle.com>

Somewhere between systemd 237 and 245, they changed the order in which a
job has its uid/gid set; capabilities applied; and working directory
set.  Whereas before they did it in an order such that you could set the
working directory to a path inaccessible to 'nobody' (either because
they did it before changing the uid or after adding capabilities), now
they don't and users instead get a service failure:

xfs_scrub@-boot.service: Changing to the requested working directory failed: Permission denied
xfs_scrub@-boot.service: Failed at step CHDIR spawning /usr/sbin/xfs_scrub: Permission denied
xfs_scrub@-boot.service: Main process exited, code=exited, status=200/CHDIR

Regardless, xfs_scrub works just fine with PWD set to /, so remove that
directive.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 scrub/xfs_scrub@.service.in |    1 -
 1 file changed, 1 deletion(-)

diff --git a/scrub/xfs_scrub@.service.in b/scrub/xfs_scrub@.service.in
index 56acea67..6fb3f6ea 100644
--- a/scrub/xfs_scrub@.service.in
+++ b/scrub/xfs_scrub@.service.in
@@ -5,7 +5,6 @@ Documentation=man:xfs_scrub(8)
 
 [Service]
 Type=oneshot
-WorkingDirectory=%I
 PrivateNetwork=true
 ProtectSystem=full
 ProtectHome=read-only

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] xfs_scrub: don't set WorkingDirectory= in systemd job
  2020-04-14 15:43 [PATCH] xfs_scrub: don't set WorkingDirectory= in systemd job Darrick J. Wong
@ 2020-04-14 16:40 ` Eric Sandeen
  0 siblings, 0 replies; 2+ messages in thread
From: Eric Sandeen @ 2020-04-14 16:40 UTC (permalink / raw)
  To: Darrick J. Wong, Eric Sandeen; +Cc: xfs

On 4/14/20 10:43 AM, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Somewhere between systemd 237 and 245, they changed the order in which a
> job has its uid/gid set; capabilities applied; and working directory
> set.  Whereas before they did it in an order such that you could set the
> working directory to a path inaccessible to 'nobody' (either because
> they did it before changing the uid or after adding capabilities), now
> they don't and users instead get a service failure:
> 
> xfs_scrub@-boot.service: Changing to the requested working directory failed: Permission denied
> xfs_scrub@-boot.service: Failed at step CHDIR spawning /usr/sbin/xfs_scrub: Permission denied
> xfs_scrub@-boot.service: Main process exited, code=exited, status=200/CHDIR
> 
> Regardless, xfs_scrub works just fine with PWD set to /, so remove that
> directive.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>

systemd is a black box to me but given this change is self contained and
scrub is "experimental" let's go for it? ;)  I'll pull this in.

Reviewed-by: Eric Sandeen <sandeen@redhat.com>

> ---
>  scrub/xfs_scrub@.service.in |    1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/scrub/xfs_scrub@.service.in b/scrub/xfs_scrub@.service.in
> index 56acea67..6fb3f6ea 100644
> --- a/scrub/xfs_scrub@.service.in
> +++ b/scrub/xfs_scrub@.service.in
> @@ -5,7 +5,6 @@ Documentation=man:xfs_scrub(8)
>  
>  [Service]
>  Type=oneshot
> -WorkingDirectory=%I
>  PrivateNetwork=true
>  ProtectSystem=full
>  ProtectHome=read-only
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-04-14 16:40 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-14 15:43 [PATCH] xfs_scrub: don't set WorkingDirectory= in systemd job Darrick J. Wong
2020-04-14 16:40 ` Eric Sandeen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).