On Mon, Jun 25, 2018 at 11:14:37AM +0100, Iain Rae wrote: > > > 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. But there are various scenarios in which the user program will get called, no matter what the $PATH ordering is. For example, the user might create ~/bin/clang, and clang.rpm might not be installed. Then any script which tries to autodetect a compiler will call it. It's just not possible to guard against naming clashes through 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. But if they're going to do it anyway (which they will, since they wrote their program to use it), they will face exactly the same problems. The only difference is that we require them to take an extra non-obvious configuration step. At least now the rule is clear: "anything in ~/bin overrides system commands, be careful of name clashes", and when the user manipulates the path on their own the rule is "anything in ~/bin might override system commands after you have done these magic steps and you remembered to reload all bash instances". > > 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. Fedora right now has 2000+ commands, and non-advanced users don't and shouldn't have to care. Instead, anything which results in the user finishing their task successfully qualifies as "better". From the user POV the new ordering just makes things slightly easier. 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/QUOCVYDV4USNZS4JCIGAMD4VOONME5WE/
