On 25/06/18 10:20, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 25, 2018 at 12:21:46AM +0100, Iain Rae wrote:
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.
You say:
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.
but then
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.
which seems at odds to me.
not really in the first scenario I gave the user decided to change his
environment and despite warnings shot himself in the foot, in the second
the user was handed a loaded gun with no safety and also managed to
shoot himself in the foot. The difference is that in the latter scenario
you can't just shrug your shoulders and go "users", you have to accept
some of the responsibility for overriding the system commands with the
path ordering.
Essentially, you're trying to use the
(supposed) stupidity of university administration to justify a certain
policy choice.
No I'm trying to point out that if there are going to be namespace
issues caused by a user creating tools then you're safer having the user
make a conscious decision to resolve it whether it be by manipulating
their path,changing their executable name, copying their tool over the
original binary.......whatever.
That cannot work, at least because such choices
would be completely arbitrary. Let's discuss the actual merits instead.
I agree that name clashes are an issue. This happens with packaged
software, we even have guidelines for that case [1], and with
unpackaged certainly too. But the order in $PATH doesn't make this
strictly worse or better. Instead, it makes some cases better
(I wrote a homework assignment and it works, even though I later
learnt that there's specialized tool with the same name), and some
cases worse (I wrote a tool to calculate housing area called "locale"
and now my login generates error messages). Using non-conflicting
names is something that everybody has to learn, and we can't forbid
$PATH changes because of potential conflicts.
I don't see either of those as better, the second certainly isn't and in
the first case you didn't find out about the system tool until later.
Surely it's "better" to find out about the specialised tool earlier and
decide whether you're going to use it or not.
The (new) order has a clear DWIM aspect: the user puts an executable
in $PATH, and they expect this executable to be used. For me Linux
is about giving control to the user, meaning that they also need to
know what they are doing, and that's just another aspect of it.
[1] https://fedoraproject.org/wiki/Packaging:Conflicts#Binary_Name_Conflicts
Zbyszek
_______________________________________________
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/LVY6WAWGSRTO2ISNNUTWDYR7M6OLMTIB/
--
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/XLAR6ESW7HYPVUDQILUTTCQXY3VCEH77/
