Compare commits

...

8 Commits

Author SHA1 Message Date
Michael Kerrisk 4d7a648597 mount_namespaces.7: SEE ALSO: add mount_setattr(2)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-08-13 01:21:53 +02:00
Michael Kerrisk 053132a882 statx.2: srcfix: semantic newlines
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-08-13 01:21:53 +02:00
NeilBrown 728009a474 statx.2: Document STATX_MNT_ID
Linux 5.8 adds STATX_MNT_ID and stx_mnt_id.
Add description to statx.2

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-08-13 01:21:53 +02:00
Michael Kerrisk 4c313d979d mount_setattr.2: srcfix: add note explaining Christian's use of -ve dirfd values
From email with Christian Brauner:

>>>>>>           int fd_tree = open_tree(-EBADF, source,
>>>>>>                        OPEN_TREE_CLONE | OPEN_TREE_CLOEXEC |
>>>>>>                        AT_EMPTY_PATH | (recursive ? AT_RECURSIVE : 0));
>>>>>
>>>>> ???
>>>>> What is the significance of -EBADF here? As far as I can tell, it
>>>>> is not meaningful to open_tree()?
>>>>
>>>> I always pass -EBADF for similar reasons to [2]. Feel free to just use -1.
>>>
>>> ????
>>> But here, both -EBADF and -1 seem to be wrong. This argument
>>> is a dirfd, and so should either be a file descriptor or the
>>> value AT_FDCWD, right?
>>
>> [1]: In this code "source" is expected to be absolute. If it's not
>>      absolute we should fail. This can be achieved by passing -1/-EBADF,
>>      afaict.
>
> D'oh! Okay. I hadn't considered that use case for an invalid dirfd.
> (And now I've done some adjustments to openat(2),which contains a
> rationale for the *at() functions.)
>
> So, now I understand your purpose, but still the code is obscure,
> since
>
> * You use a magic value (-EBADF) rather than (say) -1.
> * There's no explanation (comment about) of the fact that you want
>   to prevent relative pathnames.
>
> So, I've changed the code to use -1, not -EBADF, and I've added some
> comments to explain that the intent is to prevent relative pathnames.
> Okay?

Sounds good.

>
> But, there is still the meta question: what's the problem with using
> a relative pathname?

Nothing per se. Ok, you asked so it's your fault:
When writing programs I like to never use relative paths with AT_FDCWD
because. Because making assumptions about the current working directory
of the calling process is just too easy to get wrong; especially when
pivot_root() or chroot() are in play.
My absolut preference (joke intended) is to open a well-known starting
point with an absolute path to get a dirfd and then scope all future
operations beneath that dirfd. This already works with old-style
openat() and _very_ cautious programming but openat2() and its
resolve-flag space have made this **chef's kiss**.
If I can't operate based on a well-known dirfd I use absolute paths with
a -EBADF dirfd passed to *at() functions.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-08-13 01:21:46 +02:00
Michael Kerrisk 669d6302cb fanotify_mark.2: tfix
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-08-13 01:21:08 +02:00
Michael Kerrisk d53b1b1730 open.2: Add mount_setattr(2) to list of 'dirfd' APIs
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-08-13 01:21:08 +02:00
Michael Kerrisk af35474e4f mount_setattr.2: ffix
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-08-13 01:21:08 +02:00
Michael Kerrisk a3ade5b2b1 mount.2: SEE ALSO: add mount_setattr(2)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-08-13 01:21:01 +02:00
6 changed files with 30 additions and 2 deletions

View File

@ -83,7 +83,7 @@ contains
.BR FAN_MARK_FILESYSTEM ,
all marks for filesystems are removed from the group.
Otherwise, all marks for directories and files are removed.
No flag other than and at most one of the flags
No flag other than, and at most one of, the flags
.B FAN_MARK_MOUNT
or
.B FAN_MARK_FILESYSTEM

View File

@ -960,6 +960,7 @@ for details of this file.
.BR mountpoint (1),
.BR chroot (2),
.BR ioctl_iflags (2),
.BR mount_settatr (2),
.BR pivot_root (2),
.BR umount (2),
.BR mount_namespaces (7),

View File

@ -897,7 +897,8 @@ static inline int
mount_setattr(int dirfd, const char *pathname, unsigned int flags,
struct mount_attr *attr, size_t size)
{
return syscall(SYS_mount_setattr, dirfd, pathname, flags, attr, size);
return syscall(SYS_mount_setattr, dirfd, pathname, flags,
attr, size);
}
static inline int
@ -980,6 +981,18 @@ main(int argc, char *argv[])
/* In the following, \-1 as the \(aqdirfd\(aq argument ensures that
open_tree() fails if \(aqsource\(aq is not an absolute pathname. */
.\" Christian Brauner
.\" When writing programs I like to never use relative paths with AT_FDCWD
.\" because. Because making assumptions about the current working directory
.\" of the calling process is just too easy to get wrong; especially when
.\" pivot_root() or chroot() are in play.
.\" My absolut preference (joke intended) is to open a well-known starting
.\" point with an absolute path to get a dirfd and then scope all future
.\" operations beneath that dirfd. This already works with old-style
.\" openat() and _very_ cautious programming but openat2() and its
.\" resolve-flag space have made this **chef's kiss**.
.\" If I can't operate based on a well-known dirfd I use absolute paths
.\" with a -EBADF dirfd passed to *at() functions.
int fd_tree = open_tree(\-1, source,
OPEN_TREE_CLONE | OPEN_TREE_CLOEXEC |

View File

@ -1642,6 +1642,7 @@ a directory file descriptor argument
.BR linkat (2),
.BR mkdirat (2),
.BR mknodat (2),
.BR mount_setattr (2),
.BR move_mount (2),
.BR name_to_handle_at (2),
.BR open_tree (2),

View File

@ -77,6 +77,7 @@ struct statx {
containing the filesystem where the file resides */
__u32 stx_dev_major; /* Major ID */
__u32 stx_dev_minor; /* Minor ID */
__u64 stx_mnt_id; /* Mount ID */
};
.EE
.in
@ -258,6 +259,7 @@ STATX_SIZE Want stx_size
STATX_BLOCKS Want stx_blocks
STATX_BASIC_STATS [All of the above]
STATX_BTIME Want stx_btime
STATX_MNT_ID Want stx_mnt_id (since Linux 5.8)
STATX_ALL [All currently available fields]
.TE
.in
@ -411,6 +413,14 @@ The device on which this file (inode) resides.
.IR stx_rdev_major " and " stx_rdev_minor
The device that this file (inode) represents if the file is of block or
character device type.
.TP
.I stx_mnt_id
.\" commit fa2fcf4f1df1559a0a4ee0f46915b496cc2ebf60
The mount ID of the mount containing the file.
This is the same number reported by
.BR name_to_handle_at (2)
and corresponds to the number in the first field in one of the records in
.IR /proc/self/mountinfo .
.PP
For further information on the above fields, see
.BR inode (7).
@ -573,9 +583,11 @@ is Linux-specific.
.BR access (2),
.BR chmod (2),
.BR chown (2),
.BR name_to_handle_at (2),
.BR readlink (2),
.BR stat (2),
.BR utime (2),
.BR proc (5),
.BR capabilities (7),
.BR inode (7),
.BR symlink (7)

View File

@ -1124,6 +1124,7 @@ See
.BR unshare (1),
.BR clone (2),
.BR mount (2),
.BR mount_setattr (2),
.BR pivot_root (2),
.BR setns (2),
.BR umount (2),