From: Richard Weinberger <richard@nod.at>
To: "Marko Petrović" <petrovicmarko2006@gmail.com>
Cc: linux-um <linux-um@lists.infradead.org>,
anton ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [PATCH v2 2/2] hostfs: store permissions in extended attributes
Date: Fri, 14 Apr 2023 19:59:05 +0200 (CEST) [thread overview]
Message-ID: <1727651667.63467.1681495145812.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <CRWO54DLBZE8.1F6QOOS3VHSNI@laptop-fedora>
----- Ursprüngliche Mail -----
> Von: "Marko Petrović" <petrovicmarko2006@gmail.com>
> About using -1 for uid and gid, in documentation for chown it is stated
> that -1 shall be used if the desired value should not be changed, since
> normally chown(2) accepts both uid and gid for changing in one system
> call.
> In the concrete implementation, since the underlying type is unsigned
> int, the -1 will be written in 2's complement and then treated as an
> unsigned positive number. For the size of 4 bytes for unsigned int, the
> resulting number is 4294967295. That is also the maximum possible number
> of users on Linux, but Linux user IDs go from 0 to 4294967294 so that
> last one is outside UID space and reserved as "don't change" flag for
> chown(2).
You're totally right. I should have checked the manpage before.
> In regard to the store of values in platform independent way, in my
> humble opinion, Johannes' recommendation may be preferred (storing all
> permissions in one string) because besides this it also solves the
> problem of one setxattr() succeding and other failing (for whatever
> reason may that happen) in uml_chown().
Storing them as string is also fine by me. :-)
Thanks,
//richard
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2023-04-14 17:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 22:30 Document new xattrperm flag Marko Petrović
2023-04-13 22:30 ` [PATCH 1/2] " Marko Petrović
2023-04-14 7:17 ` Johannes Berg
2023-04-13 22:30 ` [PATCH 2/2] hostfs: store permissions in extended attributes Marko Petrović
2023-04-14 2:33 ` [PATCH v2 " Marko Petrović
2023-04-14 7:40 ` Johannes Berg
2023-04-14 17:19 ` Marko Petrović
2023-04-18 8:26 ` Johannes Berg
2023-04-25 16:10 ` Marko Petrović
2023-04-14 10:54 ` Richard Weinberger
2023-04-14 17:52 ` Marko Petrović
2023-04-14 17:59 ` Richard Weinberger [this message]
2023-04-15 16:48 ` [PATCH v3 " Marko Petrović
2023-04-16 17:24 ` Marko Petrović
2023-04-18 8:31 ` Johannes Berg
2023-04-25 16:35 ` Marko Petrović
2023-04-25 17:11 ` Johannes Berg
2023-08-28 19:48 ` Richard Weinberger
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=1727651667.63467.1681495145812.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=anton.ivanov@cambridgegreys.com \
--cc=johannes@sipsolutions.net \
--cc=linux-um@lists.infradead.org \
--cc=petrovicmarko2006@gmail.com \
/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.