GNU bug report logs -
#32127
ln: add option to fall-back to softlink if hardlink fails
Previous Next
Full log
View this message in rfc822 format
Michael Stone wrote:
> On Tue, Jul 17, 2018 at 01:25:59AM -0700, L A Walsh wrote:
>
>> I am not suggesting handing out alternates when you have a
>> choice. I'm suggesting doing something useful in a case where there are
>> no alternates and no downsides. If you can come up with a case where
>> a symlink to a directory would do more harm than a hardlink, I might agree,
>> but in this case, hardlinks are not supported. So there can be no
>> "dramatic consequences". I.e. that sounds more like FUD for the sake
>> of argument than a sound engineering analysis.
>>
>
> You want to change the semantics of a command that's been around for 40
> years, which can be used as an atomic primitive, which has the very
> simple semantics of "make this hard link or fail", and your idea of a
> "sound engineering analysis" is "I don't see how this could cause a
> problem"?
>
----
I can't think of a similar failure mode that I'd want a hard link
created, so I can't say I'd be in favor of that or not.
In this case, we aren't talking about atomic primitives -- or hard
links. If you can make a hard link to a directory, I'll stand corrected,
but this is using 'ln' to create a sym link to a directory -- something
that can't fail in standard linux.
I don't see how this could cause a problem = I see no way for this to cause
a problem => I assert it can't in normal usage. If you create an OS where
symlinking a directory removes it, then that is not what we are talking
about here.
OTOH, Just as redhat et al changed the semantics of both symlinks and
hardlinks via a setting in the kernel, I suppose a solution could be
implemented there: if the kernel detects an attempted hardlink to a
directory, it creates a symlink instead.
Do you really see modifying the linux kernel and how it handles links as
being safer than adding the proposed behavior to 'ln'? I would be
surprised if many linux users knew where to disable the new behaviors
(which are enabled
by default in many distros) that change default semantics. I suspect
most users weren't even aware of the change, though I hit the change on
the first new kernel with the features. The features were based on 2 linux
security firms -- one being gr_security -- the company that tried to silence
a security researcher pointing out their poor security practices.
A review of the stated reasons for making these kernel changes points to
their them being necessary to get around other poor security decisions
that most unix old-hands knew ages ago -- reasons for having tmp files on
separate partitions from user, tmp, and system files, and reasons why adding
new security features that don't apply to root can cause problems.
(most users can rely on not accidently overwriting someone elses files in
/tmp. Since root can override such restrictions, they can more easily
be exposed to disintegrous files.
Anyway, since only values 0/1 were used for symlink control, it would be
easy to say, value==2, would auto create a symlink to a dir when any
type of link is attempted.
Of course, I was just suggesting an ease-of-use change for the 'ln' program
to create the only viable type of link one can make when trying to make
one pointing to a directory. But if you think that's too risky despite
not being able to come up with any solid examples, then the same feature
could
be built into the kernel and probably with less FUD.
Note that the the change to ln was to follow along in the path of 'cp
-rl', where even though hard-linking is specified, "creates" directories
-- which
would seem to violate your "atomic primitive" behavior, no?
>
>
>
This bug report was last modified 6 years and 231 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.