I have encountered an interesting situation. I have a USB disk drive auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it) and it is mounted with "nosuid" (which is normal). But I would like it to
be mounted with suid working. It seems I should be able to do something like:
# mount -o remount,suid /dev/sdb1
but that generates err msg "invalid option or not mounted" (*) (as does
every variation of the above that I've tried).
I also tried "nonosuid",
but that doesn't work either.
(*) "mount" is notorious for giving "Ken Thompson style" error messages (i.e., the only error message you'll ever need is "No").
On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:
I have encountered an interesting situation. I have a USB disk drive
auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
and it is mounted with "nosuid" (which is normal). But I would like it to >> be mounted with suid working. It seems I should be able to do something
like:
# mount -o remount,suid /dev/sdb1
but that generates err msg "invalid option or not mounted" (*) (as does
every variation of the above that I've tried).
That's strange. mount(8) explicitly names "suid" as an option, with the >explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.
In article <uvud53$30gsv$[email protected]>,
Lew Pitcher <[email protected]> wrote:
On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:
I have encountered an interesting situation. I have a USB disk drive
auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
and it is mounted with "nosuid" (which is normal). But I would like it to >>> be mounted with suid working. It seems I should be able to do something >>> like:
# mount -o remount,suid /dev/sdb1
but that generates err msg "invalid option or not mounted" (*) (as does
every variation of the above that I've tried).
That's strange. mount(8) explicitly names "suid" as an option, with the >>explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.
OK - that's my reason for posting. To find out that it "should" work.
That there is an option for it.
Turns out that it works if I use the mount point rather than the device. I.e.,:
# mount -o remount,suid /path/to/wherever/it/was/mounted
works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount point (for a mounted device - i.e., once it has been mounted); they are basically synonymous. But this seems to be an exception.
Kenny McCormack <[email protected]> wrote at 20:39 this Friday (GMT):
In article <uvud53$30gsv$[email protected]>,
Lew Pitcher <[email protected]> wrote:
On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:
I have encountered an interesting situation. I have a USB disk drive
auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
and it is mounted with "nosuid" (which is normal). But I would like it to >>>> be mounted with suid working. It seems I should be able to do something >>>> like:
# mount -o remount,suid /dev/sdb1
but that generates err msg "invalid option or not mounted" (*) (as does >>>> every variation of the above that I've tried).
That's strange. mount(8) explicitly names "suid" as an option, with the >>>explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.
OK - that's my reason for posting. To find out that it "should" work.
That there is an option for it.
Turns out that it works if I use the mount point rather than the device.
I.e.,:
# mount -o remount,suid /path/to/wherever/it/was/mounted
works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount
point (for a mounted device - i.e., once it has been mounted); they are
basically synonymous. But this seems to be an exception.
Strange, I thought remount worked with the block device..
Turns out that it works if I use the mount point rather than the device.
I.e.,:
# mount -o remount,suid /path/to/wherever/it/was/mounted
works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount
point (for a mounted device - i.e., once it has been mounted); they are
basically synonymous. But this seems to be an exception.
Strange, I thought remount worked with the block device..
candycanearter07 <[email protected]>
writes:
Kenny McCormack <[email protected]> wrote at 20:39 this Friday (GMT):
In article <uvud53$30gsv$[email protected]>,
Lew Pitcher <[email protected]> wrote:
On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:
I have encountered an interesting situation. I have a USB disk drive >>>>> auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
and it is mounted with "nosuid" (which is normal). But I would like it to
be mounted with suid working. It seems I should be able to do something >>>>> like:
# mount -o remount,suid /dev/sdb1
but that generates err msg "invalid option or not mounted" (*) (as does >>>>> every variation of the above that I've tried).
That's strange. mount(8) explicitly names "suid" as an option, with the >>>>explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.
OK - that's my reason for posting. To find out that it "should" work.
That there is an option for it.
Turns out that it works if I use the mount point rather than the device. >>> I.e.,:
# mount -o remount,suid /path/to/wherever/it/was/mounted
works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount >>> point (for a mounted device - i.e., once it has been mounted); they are
basically synonymous. But this seems to be an exception.
Strange, I thought remount worked with the block device..
I haven't used remount much but I'll make one observation... A block
device can be mounted in more than one place, so it would make sense for remount to need the mount point rather than the device to be sure of
what needs to be remounted.
I don't think I've seen multiple mount points before
On Sun, 21 Apr 2024 13:40:02 -0000 (UTC), candycanearter07 wrote:
I don't think I've seen multiple mount points before
Linux calls them “bind mounts”. Very handy, for example with containers, to give the guest userland visibility into selected parts of the host filesystem.
Lawrence D'Oliveiro <[email protected]d> wrote at 00:11 this Monday (GMT):
On Sun, 21 Apr 2024 13:40:02 -0000 (UTC), candycanearter07 wrote:
I don't think I've seen multiple mount points before
Linux calls them “bind mounts”. Very handy, for example with
containers,
to give the guest userland visibility into selected parts of the host
filesystem.
Makes sense, since you can't hard link directories.
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07 <[email protected]> wrote in <v12on9$ihfm$[email protected]>:
... you can't hard link directories.
Sometimes, you can, depending on OS and filesystem:
https://jameshunt.us/writings/linking-dirs-in-macos/
IIRC, Apple's Time Machine uses this capability.
BTW, I'm not mentioning this because I think it's a good idea;
the Unix puritan in me abhors hard-linked directories.
bind mounts are different, because they don't alter the filesystem
structure. Otherwise, you might end up with an un-fsck-able
filesystem.
On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
<[email protected]> wrote in
<v12on9$ihfm$[email protected]>:
... you can't hard link directories.
Sometimes, you can, depending on OS and filesystem:
https://jameshunt.us/writings/linking-dirs-in-macos/
IIRC, Apple's Time Machine uses this capability.
BTW, I'm not mentioning this because I think it's a good idea;
the Unix puritan in me abhors hard-linked directories.
They are a very, very, very, very bad idea. And completely unnecessary.
They are a very, very, very, very bad idea. And completely unnecessary.
Why are they a bad idea? Can you show examples? I can't see it. Thanks!
Probably because there isn't much point (not that IMO there's much point to hard links anyway) as when you delete the directory you'll delete all the files inside but the now empty directory will still exist wherever its hard link
is.
Lawrence D'Oliveiro <[email protected]d> writes:
On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
<[email protected]> wrote in
<v12on9$ihfm$[email protected]>:
... you can't hard link directories.
Sometimes, you can, depending on OS and filesystem:
https://jameshunt.us/writings/linking-dirs-in-macos/
IIRC, Apple's Time Machine uses this capability.
BTW, I'm not mentioning this because I think it's a good idea;
the Unix puritan in me abhors hard-linked directories.
They are a very, very, very, very bad idea. And completely unnecessary.
Why are they a bad idea? Can you show examples? I can't see it. Thanks!
Lawrence D'Oliveiro <[email protected]d> writes:
On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
<[email protected]> wrote in
<v12on9$ihfm$[email protected]>:
... you can't hard link directories.
Sometimes, you can, depending on OS and filesystem:
https://jameshunt.us/writings/linking-dirs-in-macos/
IIRC, Apple's Time Machine uses this capability.
BTW, I'm not mentioning this because I think it's a good idea;
the Unix puritan in me abhors hard-linked directories.
They are a very, very, very, very bad idea. And completely unnecessary.
Why are they a bad idea? Can you show examples? I can't see it. Thanks!
A hardlink introduces an undetectable cyclicity in the underlying filesystem.
It must reference an inode within a specific filesystem (and, thus, cannot cross filesystems or mountpoints), and (unlike softlinks) has no other distinguishing feature. This means that you can only determine if a /directory/ hardlink has introduced a cyclical reference by actually traversing the hardlinked directory structures until you return to the starting link.
On Sat, 04 May 2024 07:50:11 -0300, Johanne Fairchild wrote:
Lawrence D'Oliveiro <[email protected]d> writes:
On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
<[email protected]> wrote in
<v12on9$ihfm$[email protected]>:
... you can't hard link directories.
Sometimes, you can, depending on OS and filesystem:
https://jameshunt.us/writings/linking-dirs-in-macos/
IIRC, Apple's Time Machine uses this capability.
BTW, I'm not mentioning this because I think it's a good idea;
the Unix puritan in me abhors hard-linked directories.
They are a very, very, very, very bad idea. And completely unnecessary.
Why are they a bad idea? Can you show examples? I can't see it. Thanks!
A hardlink introduces an undetectable cyclicity in the underlying filesystem.
It must reference an inode within a specific filesystem (and, thus, cannot cross filesystems or mountpoints), and (unlike softlinks) has no other distinguishing feature. This means that you can only determine if a /directory/ hardlink has introduced a cyclical reference by actually traversing the hardlinked directory structures until you return to the starting link.
Note that unix filesystems support a limited, controlled subset of
hardlinks: the "." and ".." directories found in each directory.
Lawrence D'Oliveiro <[email protected]d> writes:
On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
... the Unix puritan in me abhors hard-linked directories.
They are a very, very, very, very bad idea. And completely unnecessary.
Why are they a bad idea?
On Sat, 04 May 2024 07:50:11 -0300
Johanne Fairchild <[email protected]> wrote:
Lawrence D'Oliveiro <[email protected]d> writes:
On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
<[email protected]> wrote in
<v12on9$ihfm$[email protected]>:
... you can't hard link directories.
Sometimes, you can, depending on OS and filesystem:
https://jameshunt.us/writings/linking-dirs-in-macos/
IIRC, Apple's Time Machine uses this capability.
BTW, I'm not mentioning this because I think it's a good idea;
the Unix puritan in me abhors hard-linked directories.
They are a very, very, very, very bad idea. And completely unnecessary.
Why are they a bad idea? Can you show examples? I can't see it. Thanks!
Probably because there isn't much point (not that IMO there's much point to hard links anyway) as when you delete the directory you'll delete all the files inside but the now empty directory will still exist wherever its hard link
is.
On 2024-05-04, Lew Pitcher <[email protected]> wrote:
A hardlink introduces an undetectable cyclicity in the underlying filesystem.
You mean, trouble some cyclicity that is detectable with a lot of
annoying fuss, that has to be done wherever the filesystem is being recursively traversed.
It must reference an inode within a specific filesystem (and, thus, cannot >> cross filesystems or mountpoints), and (unlike softlinks) has no other
distinguishing feature. This means that you can only determine if a
/directory/ hardlink has introduced a cyclical reference by actually
traversing the hardlinked directory structures until you return to the
starting link.
If you keep the path of inodes you have visited in order to reach a
certain directory, then you can detect a cycle by checking whether a
newly visited directory is one of the elements of the path. Since
paths are reasonably short, you don't need any fancy hash data structure
for this; a linear scan will work fine in most cases, and so you can represent the path as a linked list that is allocated on the stack,
if working in C.
void recurse(..., visited_node *parent)
{
visited_node current = { .up = parent };
// ...
}
The cyclic check is simply chasing the parent->up pointers to see if any
of the visited nodes is the same object as the newly visited one.
The problem is:
1. Everything that performs traversals of the filesystem now *has* to do
this, or risk being stuck in a loop. There is a bad habit in the
Unix programming culture of people rolling their own filesystem
traversal functions. Some of them would get it wrong, ending up in
infinite loops.
2. Even if you have cycle detection, you still have the problem that
every recursive traversal performed anywhere runs the risk of
potentially visiting the entire filesystem!
Directory hard links could be restricted to being downward-only. So that
is to say, if you create a P/C -> D hard link, then X is required to be
a descendant of P, such as P/X/Y/D.
To check that without race conditions, the kernel would have to lock
down all operations on that filesystem during the link operation.
Starting at D, it could navigate the parent .. links until it hits
the root directory, P, or hits a mount point crossing. If it finds P,
then it can conclude that the link can be made. (Without TOCtoTOU
if things are properly locked down.)
Holding a lock over a complex operation like that could open an avenue
to a DOS attack against the filesystem. Imagine a swarm of threads doing directory linking operations, causing that lock to be excessively held.
The descendant restriction would make directory hardlinks inapplicable
to some people's use cases. (Oh well, they'd have to use symlinks
for those situations.)
[email protected] writes:
On Sat, 04 May 2024 07:50:11 -0300
Johanne Fairchild <[email protected]> wrote:
Lawrence D'Oliveiro <[email protected]d> writes:Probably because there isn't much point (not that IMO there's much point to >> hard links anyway) as when you delete the directory you'll delete all the
On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:Why are they a bad idea? Can you show examples? I can't see it. Thanks! >>
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
<[email protected]> wrote in
<v12on9$ihfm$[email protected]>:
... you can't hard link directories.
Sometimes, you can, depending on OS and filesystem:
https://jameshunt.us/writings/linking-dirs-in-macos/
IIRC, Apple's Time Machine uses this capability.
BTW, I'm not mentioning this because I think it's a good idea;
the Unix puritan in me abhors hard-linked directories.
They are a very, very, very, very bad idea. And completely unnecessary. >>>
files inside but the now empty directory will still exist wherever
its hard link
is.
Oh, I see. And if we were to fix this by removing the directory as well
in the two or more places it was linked to? Wouldn't it be useful as a single directory that has two absolute paths? That seems useful to me.
Johanne Fairchild wrote:
Lawrence D'Oliveiro <[email protected]d> writes:
vallor wrote:
... the Unix puritan in me abhors hard-linked directories.
They are a very, very, very, very bad idea. And completely
unnecessary.
Why are they a bad idea?
Consider these two questions:
* How do you detect reference cycles?
* What happens if you don’t?
Lawrence D'Oliveiro <[email protected]d> writes:
* How do you detect reference cycles?
Multiple cycle-detection algorithms have been well known for decades.
* What happens if you don’t?
Something gets stuck in a loop.
...
You’re on stronger grounds with “unnecessary” but a three-very bad idea?
Insufficient evidence at best.
You're on stronger grounds with unnecessary but a three-very bad idea?
Insufficient evidence at best.
You think getting stuck in a loop is not a bad idea?
On Sat, 4 May 2024 14:49:19 -0000 (UTC), Lew Pitcher wrote:
Note that unix filesystems support a limited, controlled subset of
hardlinks: the "." and ".." directories found in each directory.
Even those are completely unnecessary. Their interpretation could easily
be hard-coded into the path-interpretation routines in the kernel, instead
of wasting space for these entries in every single directory on a
filesystem.
On 2024-05-04, Lawrence D'Oliveiro <[email protected]d> wrote:
On Sat, 4 May 2024 14:49:19 -0000 (UTC), Lew Pitcher wrote:
Note that unix filesystems support a limited, controlled subset of
hardlinks: the "." and ".." directories found in each directory.
Even those are completely unnecessary. Their interpretation could easily
be hard-coded into the path-interpretation routines in the kernel, instead >> of wasting space for these entries in every single directory on a
filesystem.
But they're not: it goes to the core of the Unix "everything is a
file" philosophy. Applications can and do read directories as
regular files and extract the parent from them.
No on DOS/Windows,
you can't do that, you have to use a specific syscall. It's not
"completely unnecessary", just a different way of acheiving the
same effect.
Richard Kettlewell wrote:
Lawrence D'Oliveiro <[email protected]d> writes:
* How do you detect reference cycles?
Multiple cycle-detection algorithms have been well known for decades.
How many directories would you have to lock down while checking for cycles?
How deep can your directory tree go?
* What happens if you don’t?
Something gets stuck in a loop.
...
You’re on stronger grounds with “unnecessary” but a three-very bad idea?
Insufficient evidence at best.
You think getting “stuck in a loop” is not a bad idea?
Even those are completely unnecessary. Their interpretation could easily >>> be hard-coded into the path-interpretation routines in the kernel, instead >>> of wasting space for these entries in every single directory on a
filesystem.
But they're not: it goes to the core of the Unix "everything is a
file" philosophy. Applications can and do read directories as
regular files and extract the parent from them.
Can you name one such application? Just as a warm up; then two more.
No on DOS/Windows,
you can't do that, you have to use a specific syscall. It's not
"completely unnecessary", just a different way of acheiving the
same effect.
No, you can't just read a directory as a flat file, and expect your
program to work on any file system.
In article <[email protected]>,
Kaz Kylheku <[email protected]> wrote:
...
Even those are completely unnecessary. Their interpretation could easily >>>> be hard-coded into the path-interpretation routines in the kernel, instead >>>> of wasting space for these entries in every single directory on a
filesystem.
But they're not: it goes to the core of the Unix "everything is a
file" philosophy. Applications can and do read directories as
regular files and extract the parent from them.
Can you name one such application? Just as a warm up; then two more.
I think you're taking him too literally. There are interfaces for reading directories. Not specifically read(2), but you know better than to pick
nits that way.
No on DOS/Windows,
you can't do that, you have to use a specific syscall. It's not
"completely unnecessary", just a different way of acheiving the
same effect.
No, you can't just read a directory as a flat file, and expect your
program to work on any file system.
He never used the term "flat file". That is *your* construct.
On 2024-05-04, Lawrence D'Oliveiro <[email protected]d> wrote:
On Sat, 4 May 2024 14:49:19 -0000 (UTC), Lew Pitcher wrote:
Note that unix filesystems support a limited, controlled subset of
hardlinks: the "." and ".." directories found in each directory.
Even those are completely unnecessary. Their interpretation could
easily be hard-coded into the path-interpretation routines in the
kernel, instead of wasting space for these entries in every single
directory on a filesystem.
But they're not: it goes to the core of the Unix "everything is a
file" philosophy. Applications can and do read directories as
regular files and extract the parent from them.
Lawrence D'Oliveiro <[email protected]d> writes:
You think getting “stuck in a loop” is not a bad idea?
[Non-answer]
On 2024-05-05, Andrew Smallshaw <[email protected]> wrote:
On 2024-05-04, Lawrence D'Oliveiro <[email protected]d> wrote:
On Sat, 4 May 2024 14:49:19 -0000 (UTC), Lew Pitcher wrote:
Note that unix filesystems support a limited, controlled subset of
hardlinks: the "." and ".." directories found in each directory.
Even those are completely unnecessary. Their interpretation could easily >>> be hard-coded into the path-interpretation routines in the kernel, instead >>> of wasting space for these entries in every single directory on a
filesystem.
But they're not: it goes to the core of the Unix "everything is a
file" philosophy. Applications can and do read directories as
regular files and extract the parent from them.
Can you name one such application? Just as a warm up; then two more.
No on DOS/Windows,
you can't do that, you have to use a specific syscall. It's not
"completely unnecessary", just a different way of acheiving the
same effect.
No, you can't just read a directory as a flat file, and expect your
program to work on any file system.
Modern (as in within the last 40 years) Unixes support multiple file
systems including DOS. The directory representation is different in
different file systems. Some use B-trees and hash tables and whatnot.
On the Linux kernel, reading from a file descriptor that refers to a >directory is not allowed; it fails with errno == EISDIR. (Not sure
whether that's at the VFS layer, or whether specific filesystems refuse
that individually.)
Not, that is, unless you run some kind of “garbage collection” pass over the filesystem, to reclaim orphaned storage. Filesystems are not typically designed with this sort of requirement in mind. Wonder why?
GC has been used in other contexts for decades. In general you can’t reliably infer from something not being done that it would be a bad
idea ...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 145:52:15 |
| Calls: | 12,089 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,500 |