On 22/06/18 20:56, Till Maas wrote:
On Fri, Jun 22, 2018 at 07:24:54PM +0200, Björn Persson wrote:
Till Maas wrote:
I do not see any reason why a user would put something in ~/bin that
would mask something in /usr/bin except to actually mask the binary. It
is the same with other user configuration, anyone expects ~/.ssh/config
to override /etc/ssh/ssh_config instead of the other way round.
It could happen by accident. A user might put a program in ~/bin that
happens to have the same name as one in /usr/bin that the user is
unaware of, and it might break other programs which call that command
without a full pathname. Editing ~/.ssh/config affects only SSH, and
isn't likely to break something unrelated.
That's one reason why I'm not convinced that this change is a good
idea. It obviously has nothing to do with security though. It's a
matter of safety, which is different from security.
In your opinion, how does the user act nowadays when something in
/usr/bin masks their tool that they installed in ~/bin? I would assume
that they will change the path, since installing the tool there is what
they wanted.
If the original path is /usr/bin:..../~/bin then they should find out
fairly quickly that there is a system command with the same name (we've
never had someone write a read mail (rm) command but we've had some
interesting ones). If they decide to change the name of their command
(...to ream...?) then probably everyone goes away happy. If they decide
that no, actually rm is a really good name for a mail client and they're
going to mask the system tool then they get to own the consequences,
it's their namespace, if they couldn't take a joke they shouldn't have
joined. In our environment (university computing science department) if
they had issues with running coursework because they were masking system
commands we'd point out this probably isn't a good thing to do. If they
persisted and couldn't finish coursework then they'll not get much
sympathy from the academic staff.
Conversely if we had ~/bin:../usr/bin then the first the user is going
to know that there's a problem is when something tries to invoke the
system version and gets the users tool. This might be an (admittedly
badly written) tool that barfs because of an odd response, or possibly
worse acts on incorrect output but the effects are likely to be a lot
more subtle to the user. If this happened with us then User, Academic
and probably H.o.D. are going to ask why we chose to implement this and
they'll be given more time to do the work and we'll be told to change
the order.
Making it hard for users to achieve their goals usually
does not stop them.
No, and you can make life easy for your users and they will still go to
convoluted lengths to make life hard for themselves, usually by not
reading the docs. As the great Stan Laurel once said "You can lead a
horse to water but a pencil must be lead"
Also a tool with a same name in /usr/bin might also
break another user's tool that expects the user version to be available
in the PATH. I do not see how this would be better.
Again it's the users part of the Environment, they get to own the
consequences of what they do there, if it's good or bad.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/VHJIEEF23PJCHAKGR35YDG6VL4XKX37Y/
