tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Sanitizing (canonicalising) the block device name in mount_ffs ??



Le Sat, May 27, 2023 at 11:56:16PM +0700, Robert Elz a écrit :
> I'm dual-posting this to tech-kern and tech-userlevel, as while it is
> a userlevel issue, it could have kernel implications.   Please respect
> the Reply-To and send replies only to tech-userlevel
> 
> You may have noticed that a recent change (mine) to the pathadj()
> function (which converts an abritrary path name to its canonical form).
> That function is not permitted to fail, but could.   Now instead of
> failing, and returning (potential) nonsense, it exits if it cannot
> do what it is required to do (usually it can).  In practice this
> affects nothing real.
> 
> However, it affects some uses of rump - which sets up a "block device"
> in a way that its name cannot be canonicalised.   It was relying upon
> the way that pathadj() happens to work (based upon how realpath(3) works)
> to make things function - pathadj() was issuing an error message, which
> some rump using ATF tests were simply ignoring (deliberately).
> 
> Yesterday, I was trying to find a way to make this all work - unsuccessfully.
> 
> Today I am wondering why we need to bother?    That is, not why we bother
> with rump, not even why rump has to make its magic etfs work the way it
> does.   But why we need to canonicalise the block device name for mount.
> 

Isn't it because in order to be able to compare strings, the path has
to have an uniq (canonical) form, independent from the way the user
enters it? For example, at the user level, how mount(8) could compare,
given only one argument, to what is in /etc/fstab without trying
first to give the pathname given some normal form? (I imagine that
with the NAME=...  syntax in fstab, there are now alternatives to
the canonical form, but in a limited amount).
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


Home | Main Index | Thread Index | Old Index