Linux mount: What is the opposite of "nosuid" ?

[Kenny McCormack]

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").

Notes:
1) Googling finds lots of stuff about how (and why) to mount nosuid,
but not the opposite.
2) (Obviously) I'm not interested in any solutions that need a time
machine or involve editing /etc/fstab or that involve un-mounting
it and mounting it over from scratch.

It seems there should be a way with remount. "man mount" talks a fair bit
about using "--bind" as an alternative to "-o remount", but I did not
follow that very well. I've used "-o remount" many times in the past,
successfully.

[Lew Pitcher]

Post by Kenny McCormack
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
# 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.

BUT.... suid (like a number of other options) only applies iff the underlying
filesystem supports set-user-identifier and set-group-identifier bits. Some
filesystems don't (like FAT and NTFS-based filesystems).

Are you trying to mount a non-unix filesystem?

Post by Kenny McCormack
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").

[snip]

HTH

[Kenny McCormack]

Post by Lew Pitcher

Post by Kenny McCormack
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
# 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
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.

[candycanearter07]

Post by Kenny McCormack

Post by Lew Pitcher

Post by Kenny McCormack
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
# 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
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.
# 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..

[Ben Bacarisse]

Post by candycanearter07

Post by Kenny McCormack

Post by Lew Pitcher

Post by Kenny McCormack
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
# 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
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.
# 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.

[candycanearter07]

Post by Ben Bacarisse

Post by candycanearter07

Post by Kenny McCormack

Post by Lew Pitcher

Post by Kenny McCormack
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
# 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
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.
# 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.

Oh, I never considered that. I don't think I've seen multiple mount
points before.

[Lawrence D'Oliveiro]

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.

[candycanearter07]

Post by Lawrence D'Oliveiro

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.

[vallor]

On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07

Post by candycanearter07

Post by Lawrence D'Oliveiro

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.

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.

[Lawrence D'Oliveiro]

Post by vallor
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07

... you can't hard link directories.

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.

Post by vallor
bind mounts are different, because they don't alter the filesystem
structure. Otherwise, you might end up with an un-fsck-able
filesystem.

Fun fact: Linux doesn’t actually distinguish between different mounts of
the same filesystem (in the sense that one is the “original” mount and the
others are not). That is, you can keep a later “bind” mount, and remove
the original non-“bind” mount, and it still works.

[Johanne Fairchild]

Post by Lawrence D'Oliveiro

Post by vallor
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07

... you can't hard link directories.

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!

[Kenny McCormack]

In article <***@tudado.org>,
Johanne Fairchild <***@tudado.org> wrote:
...

Post by Johanne Fairchild

Post by Lawrence D'Oliveiro
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!

The poster who used too many "Very"s is a known crank.

Generally, the more "Very"s you use, the worse is your argument.

Or, as Mark Twain once put it:

A young writer asked me how to edit his writing. I told him that he
should go through and replace every occurrence of the word "very" with
the word "damn". His editor would then remove every occurrence of the
later word, and then things would be as they should be.

So at our house, with this story in mind, whenever we use the word "very"
in conversation, we immediately change it to "damn". So, the above would
be:

They are a damn, damn, damn, damn bad idea. And completely unnecessary.

and after editing:

They are a bad idea. And completely unnecessary.

[M***@dastardlyhq.com]

On Sat, 04 May 2024 07:50:11 -0300

Post by Johanne Fairchild

Post by Lawrence D'Oliveiro

Post by vallor
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07

... you can't hard link directories.

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.

[Kaz Kylheku]

Post by M***@dastardlyhq.com
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.

This problem happens anyway when one or more processes have that
directory as their root or cwd, referring to it by open inode.

[Kenny McCormack]

In article <v15gcp$18g38$***@dont-email.me>, <***@dastardlyhq.com> wrote:
...

Post by M***@dastardlyhq.com
Probably because there isn't much point (not that IMO there's much point to
hard links anyway) ...

Without hard links, you could not have a Unix filesystem.

So, you do need them.

[M***@dastardlyhq.com]

On Sat, 4 May 2024 14:40:54 -0000 (UTC)

Post by Kenny McCormack
....

Post by M***@dastardlyhq.com
Probably because there isn't much point (not that IMO there's much point to
hard links anyway) ...

Without hard links, you could not have a Unix filesystem.

Why not? If you meant "." and ".." FAT copes without having these as actual
filesystem entries - they simply get interpreted by the path string parsing
system. I'm not even sure if NTFS has them as hard links either.

[Johanne Fairchild]

Post by M***@dastardlyhq.com
On Sat, 04 May 2024 07:50:11 -0300

Post by Johanne Fairchild

Post by Lawrence D'Oliveiro

Post by vallor
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07

... you can't hard link directories.

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.

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]

Post by Johanne Fairchild

Post by M***@dastardlyhq.com
On Sat, 04 May 2024 07:50:11 -0300

Post by Johanne Fairchild

Post by Lawrence D'Oliveiro

Post by vallor
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07

... you can't hard link directories.

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.

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.

Scratch all that. I should've read the entire subthread before asking.

[Lew Pitcher]

Post by Johanne Fairchild

Post by Lawrence D'Oliveiro

Post by vallor
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07

... you can't hard link directories.

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 the other hand, you can detect both softlinks and bind mounts without
directory traversal. A softlink inode contains a very specific flag to
indicate that it contains a softlink, and the system records a bind mount
in the its public mount records.

[Lew Pitcher]

Post by Lew Pitcher

Post by Johanne Fairchild

Post by Lawrence D'Oliveiro

Post by vallor
On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07

... you can't hard link directories.

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. The OS controls the
creation and deletion of /these/ hardlinks from within, as part of the mkdir(2)
and rmdir(2) syscalls. And, the only cyclical hardlink (that I know of, anyway)
lives as "/..", which links to itself.

As for a cyclical hardlink, imagine the following:
# Build a disposable directory
mkdir /tmp/dumb

# Populate the disposable directory with a cyclical hardlink
ln /tmp/dumb /tmp/dumb/dumber

# Now, let's empty the disposable directory
rm -rf /tmp/dumb

What does the "rm -rf" do when that "ln /tmp/dumb /tmp/dumb/dumber" actually
creates a hardlink from /tmp/dumb/dumber to /tmp/dumb ?

[Lawrence D'Oliveiro]

Post by Lew Pitcher
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.

[Andrew Smallshaw]

Post by Lawrence D'Oliveiro

Post by Lew Pitcher
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.

[Kaz Kylheku]

Post by Andrew Smallshaw

Post by Lawrence D'Oliveiro

Post by Lew Pitcher
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.

Post by Andrew Smallshaw
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.)

[Kenny McCormack]

In article <***@kylheku.com>,
Kaz Kylheku <643-408-***@kylheku.com> wrote:
...

Post by Kaz Kylheku

Post by Andrew Smallshaw

Post by Lawrence D'Oliveiro
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.

Post by Kaz Kylheku

Post by Andrew Smallshaw
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.

[Kaz Kylheku]

Post by Kenny McCormack
...

Post by Kaz Kylheku

Post by Andrew Smallshaw

Post by Lawrence D'Oliveiro
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.

Post by Kaz Kylheku

Post by Andrew Smallshaw
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.

I don't believe you are correct; read the original points again.
They are all quoted above, nothing snipped:

- "Applications [on Unix] can and do read directories as
regular files."

(Regular files are flat: just bytes, so it is legitimate for me to use
that word. That detail is neither here nor there anyway. You can't
read a directory even if you know how to follow its tree structure
or whatever it happens to be.)

- "[O]n DOS/Windows [...] you can't do that, you have to use
a specific syscall."

(That lands under "interfacws for reading directories" that you
allude to. So no, we don't just have to use those on Windows.)

[Dan Cross]

Post by Kaz Kylheku

Post by Andrew Smallshaw

Post by Lawrence D'Oliveiro

Post by Lew Pitcher
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.

Depends on the version of Unix. I'll pick 7th Ed. Here's three
programs that could: `cat`, `dd`, and `od`. Of course, that's
not what you mean, bt I think it's related.

Post by Kaz Kylheku

Post by Andrew Smallshaw
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.)

Sure. But by the time that sort of support for multiple
filesystem types came around, the structure of many Unix file
systems (with hard links for "." and "..") had already existed,
and there was desire to retain compatibility with existing
on-disk filesystem images. So even though the landscape is
radically different now, as you describe, history got us here.

Btw, the bigger reason that hardlinks to directories are
prohibited isn't because file tree walkers would have to be
rewritten to take care when transversing such filesystems, but
rather because automated filesystem checkers like `fsck` would
have to be a _lot_ more sophisticated to cope, and they have
the potential to do real, significant damage if they get it
wrong.

- Dan C.

[Lawrence D'Oliveiro]

Post by Andrew Smallshaw

Post by Lawrence D'Oliveiro

Post by Lew Pitcher
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.

How do they find those directories? Via their pathname. How do you get a
parent from a pathname? Simple: just drop off the last component. No need
to even read anything from the directory.

[Kaz Kylheku]

Post by Lew Pitcher
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.

Post by Lew Pitcher
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.)

[Johanne Fairchild]

Post by Kaz Kylheku

Post by Lew Pitcher
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.

Post by Lew Pitcher
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.
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.)

Thanks very much Lew Pitcher and Kaz Kylheku for the lecture. (Ignore
my previous post on the thread asking further. It's all clear now.)

[Lawrence D'Oliveiro]

Post by Johanne Fairchild

Post by Lawrence D'Oliveiro

... 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?

[Richard Kettlewell]

Post by Lawrence D'Oliveiro

Post by Johanne Fairchild

Post by Lawrence D'Oliveiro

... 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?

* How do you detect reference cycles?

Multiple cycle-detection algorithms have been well known for decades.

Post by Lawrence D'Oliveiro
* What happens if you don’t?

Something gets stuck in a loop.

In the hypothetical where hard-link directories was possible, filesystem
traversers would have to take into account the possibility of
cycles. It’d be an extra implementation detail, comparable to the way
real ones have to take into account the possibility of the filesystem
changing as they progress, or accept with the consequences if they
don’t.

You’re on stronger grounds with “unnecessary” but a three-very bad idea?
Insufficient evidence at best.

[Lawrence D'Oliveiro]

Post by Richard Kettlewell

Post by Lawrence D'Oliveiro
* 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?

Post by Richard Kettlewell

Post by Lawrence D'Oliveiro
* 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?

[Kenny McCormack]

In article <v17g26$1onvc$***@dont-email.me>,
Lawrence D'Oliveiro <***@nz.invalid> wrote:
...

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?

It *might* be a "bad idea", but it is hardly a damn, damn, damn bad idea.

[Richard Kettlewell]

Post by Lawrence D'Oliveiro

Post by Richard Kettlewell

Post by Lawrence D'Oliveiro
* 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?

Could be as little as 2. Depends on the algorithm used, what else you
can assume about the filesystem, etc.

Post by Lawrence D'Oliveiro
How deep can your directory tree go?

Post by Richard Kettlewell

Post by Lawrence D'Oliveiro
* 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?

I think my previous posting adequately covers this question.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
You think getting “stuck in a loop” is not a bad idea?

[Non-answer]

Consider three directories A, B and C which point to each other like this:

A → B ↔ C

Note this: the refcount of (number of pointers to) B is 2, and that of C
is 1.

Now consider what happens if B is removed from A. Its refcount goes to 1,
so it is not deleted.

B ↔ C

But there is no way to access it! There are no other pointers to either B
or C, so both of them are now effectively lost as far as users are
concerned--yet their space cannot be reclaimed (or that of any items that
might be in them).

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?

[Richard Kettlewell]

Post by Lawrence D'Oliveiro
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?

Again, the techniques are well understood; 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, merely that it hasn’t proved
necessary.

[Lawrence D'Oliveiro]

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 ...

Hint: think about what’s different about filesystems versus management of
main memory.

[Kenny McCormack]

In article <uvvcrr$3euft$***@dont-email.me>,
candycanearter07 <***@candycanearter07.nomail.afraid> wrote:
...

Post by candycanearter07

Post by Kenny McCormack
Turns out that it works if I use the mount point rather than the device.
# 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..

Actually, it is pretty clear at this point (moreso now than when I started
this thread - that is a Good Thing. I've learned some things from having
launched this thread) that a "mount" is a data structure associated with a
directory, not with a device. The device is one of the properties of the
data structure (that isn't necessarily present, and isn't present in all
mounts).

So, it makes sense that you should have to specify the directory (referred
to as "the target" in the man pages) in most cases. It turns out that the
one exception to this - umount-ing - is actually an historical anomaly.
According to "man 2 umount", umount used to be "umount(device)", but then
they changed it to "umount(directory)" (for a while both were supported, at
the system call level, but then the "device" form was dropped). So, I
assume that, as a courtesy and for backward compatibility, the "umount"
program substitutes the device name with the directory name before invoking
the system call.