All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: наб <nabijaczleweli@nabijaczleweli.xyz>
Cc: util-linux@vger.kernel.org
Subject: Re: [RFC] libmount: accept X-mount.{owner,group,mode}=
Date: Wed, 6 Apr 2022 13:38:14 +0200	[thread overview]
Message-ID: <20220406113814.twdo4mwkevwuayht@ws.net.home> (raw)
In-Reply-To: <20220330181300.mr66k4zghcrf4l6c@tarta.nabijaczleweli.xyz>

On Wed, Mar 30, 2022 at 08:13:00PM +0200, наб wrote:
> Which take an user, group, and mode, respectively, and set them on the
> target after mounting
> 
> This is vaguely similar to tmpfs(5)'s [ug]id= and mode= options,
> but we POSIX-parse the user- and group names
> 
> Oft requested in systemd/zram-generator, since a common use-case
> is to use it to create /tmp or an equivalent directory that needs
> to be a=rwx,o+t (or a user's private temp that needs to be owned
> by them) ‒ this is impossible without terrible hacks, cf.
> https://github.com/systemd/zram-generator/issues/150,
> https://github.com/systemd/zram-generator/issues/146, &c.
> 
> This started off as a Set{User,Group,Mode}= systemd mount unit,
> but was poetterung into libmount options:
> https://github.com/systemd/systemd/pull/22889

I see how usable this feature could be, but it also increases
complexity of the mount(8) command.

> But I'm not sure how to proceed. I've stuffed the parsing and chowning
> stage into mnt_context_finalize_mount() for ease-of-PoC, but should:
>   (a) the post-syscall error handling in mnt_context_get_mount_excode()
>       be extended to recognise MNT_ERR_MOUNTOPT?

Yes, see MNT_ERR_NAMESPACE, it the same thing. We have it in the
pre-syscall and in post-syscall sections.

>   (b) the parsing/chowning stages be split (parsing in pre-mount prep,
>       chowning in post-mount)? with a new MNT_ERR_ flag potentially?

Yes, this is probably the most robust way (don't call mount syscall if
X-mount.* is invalid).

I guess you can add tgt_owner, tgt_group and tgt_mode to libmnt_context to
keep parsed results, fill the fields in mnt_context_prepare_mount() (or so) and use
it mnt_context_do_mount() (before mnt_context_switch_ns()).

Don't forget to reset it in mnt_reset_context().

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com


  reply	other threads:[~2022-04-06 15:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 18:13 [RFC] libmount: accept X-mount.{owner,group,mode}= наб
2022-04-06 11:38 ` Karel Zak [this message]
2022-04-07 18:39   ` [RFC v2] " наб
2022-04-13  8:12     ` Karel Zak
2022-04-13 13:18       ` наб
2022-04-19 11:13     ` Karel Zak
2022-04-19 14:56       ` [PATCH v3] " наб
2022-04-21 10:19         ` Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220406113814.twdo4mwkevwuayht@ws.net.home \
    --to=kzak@redhat.com \
    --cc=nabijaczleweli@nabijaczleweli.xyz \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.