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. Essentially, you're trying to use the (supposed) stupidity of university administration to justify a certain policy choice. 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. 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/
