Re: of bash and ...sbin/
Robert Woodcock [EMAIL PROTECTED] writes: Without going in depth as to what traceroute and ping are (a fruitless flame war) Facts can not build a flame war. Opinions (about depth or somesuch) can. suffice it to say that I disagree with your deeper comment. Ok. These 'boundaries' are completely arbitrary, since as pointed out earlier, Herbert Xu isn't willing to change traceroute. Perhaps we should ask Dan Quinlan? Indeed. This way all Linux variants can go through this change. Traditionally, it was /sbin/traceroute and it makes sense to reverse this decision only when a new standard mandates it. [mv /usr/bin/mtr /usr/sbin/mtr ?] If it is really to go in sbin, then I shall also take the suid-bit off of it, since obviously only root will be using it anyway. Nope. Users will still want to use it. FWIW, suid should be replaced by a capability, anyway, sooner or later. -- Robbe
Re: of bash and ...sbin/
On 22-Mar-00, 15:59 (CST), Jacob Kuntz [EMAIL PROTECTED] wrote: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? We discussed (and argued and flamed and ...) that to death. The objection is mostly due to potential confusion (there are a lot more potential targets for command completion, and most of them are *not* what the user is looking for) and inertia, and the expectation that a user who finds value in use of traceroute or ifconfig or whatever is also a user who is capable of modifying their path. sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: of bash and ...sbin/
Jacob Kuntz [EMAIL PROTECTED] writes: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? Do you have a problem putting /sbin:/usr/sbin in your personal path? -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche
Re: of bash and ...sbin/
Date: Thu, 23 Mar 2000 08:48:47 +1100 From: Craig Sanders [EMAIL PROTECTED] To: Jacob Kuntz [EMAIL PROTECTED] Cc: Chad Miller [EMAIL PROTECTED], debian-devel@lists.debian.org Subject: Re: of bash and ...sbin/ On Wed, Mar 22, 2000 at 11:50:10AM -0500, Jacob Kuntz wrote: Chad Miller ([EMAIL PROTECTED]) wrote: I like that debian's bash package has different paths for users and the superuser, but it's caused me to question ideas behind the placement of some programs in 'sbin' directories. For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Other (questionable) ones might be /usr/sbin/fbset or /usr/sbin/lpc . not to mention ifconfig! having these utils in the non-root path is hardly a security risk. if anything, this is just to keep down helpdesk calls like what does MAKEDEV do? personally, since many of these commands print out usefull, non-security-risking data, i don't see any good reason to keep em out. we've had this flamewar before, only a few months ago. just add /sbin:/usr/sbin:/usr/local/sbin to your $PATH and be done with it. it only takes a few seconds (do it in /etc/profile if you want) and it doesn't risk breaking existing scripts. many scripts (both debian scripts and local sysadmin scripts) make use of ping, traceroute, ifconfig and others in the sbin directories. it is common practice to specify the full path to sbin binaries to avoid any potential problems with the PATH being different in different contexts (e.g. login shell vs cron environment vs su or sudo environment). moving these programs to different directories will break those scripts. the minimal benefit of moving them is greatly outweighed by the damage it would cause. in short, add the sbin directories to your PATH and move on. Agreed (mostly). It is very important that Debian have things in the same place as other Linux distros, and other common Unix flavours. Otherwise, scripts from commercial software and other stuff that isn't always as portable as it should be will be spuriously broken on Debian. Lets not not go out of our way to lay traps for vendors who we are hoping will support Debian GNU/*. It seems to me that binary locations are one of those things that Unix is stuck with, even though it would be nice if we could change them. What should be done is to add /usr/sbin and /sbin to the PATH of ordinary mortal users. There is no security issue here, since they could always add it themselves if they actively wanted to cause harm. If you were setting up restricted-shell accounts, you would need to change PATH anyway, since bash is in the standard path, which kind of defeats the restricted shell, except as an anti-cluelessness measure :) OTOH, there are programs that could move. Programs which aren't in other Unices, such as fbset, should maybe stay in /usr/sbin, since it's job is to configure the machine. The FHS (http://www.pathname.com/fhs/1.2/fsstnd-4.10.html) says that /usr/sbin has daemons, non-essential administration tools, and binaries for non-critical server programs. The administrator is not necessarily root, since settings which any user can change can be administered by anyone. I'd call changing screen settings, turning on DPMS on the console with setterm, or stuff like that, counts as admining in my book. Therefore, these programs are admin tools, but users should have /usr/sbin (and probably /sbin) in their PATH, because they can usefully use these admin programs. (even for stuff they're not allowed to change, they can get config info. It probably doesn't help them to see this config info, but they can see it if they're curious.) Everything that is more or less administrative should go in /usr/sbin, which everyone should have in their PATH. (oh yeah, did I mention that /usr/sbin should be the default PATH after you install the base system. Oh, I think I did. hehe :) One thing we should _not_ do is to have things in two places at once, with symlinks. That just sucks, IMHO :) -- #define X(x,y) x##y DUPS Secretary ; http://is2.dal.ca/~dups/ Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: of bash and ...sbin/
Miles Bader ([EMAIL PROTECTED]) wrote: Jacob Kuntz [EMAIL PROTECTED] writes: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? Do you have a problem putting /sbin:/usr/sbin in your personal path? no, do you have a problem with a more sensible default? if not, then why do you think this isn't a more sensible default? -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: of bash and ...sbin/
Steve Greenland ([EMAIL PROTECTED]) wrote: On 22-Mar-00, 15:59 (CST), Jacob Kuntz [EMAIL PROTECTED] wrote: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? We discussed (and argued and flamed and ...) that to death. The objection is mostly due to potential confusion (there are a lot more potential targets for command completion, and most of them are *not* what the user is looking for) and inertia, and the expectation that a user who finds value in use of traceroute or ifconfig or whatever is also a user who is capable of modifying their path. finnally! a valid argument! i submit. sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: of bash and ...sbin/
For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Right. But the maintainer refuses to do the right thing. End of the thread.
Re: of bash and ...sbin/
Agreed (mostly). It is very important that Debian have things in the same place as other Linux distros, and other common Unix flavours. Otherwise, scripts from commercial software and other stuff that isn't always as portable as it should be will be spuriously broken on Debian. Lets not not go out of our way to lay traps for vendors who we are hoping will support Debian GNU/*. It seems to me that binary locations are one of those things that Unix is stuck with, even though it would be nice if we could change them. What should be done is to add /usr/sbin and /sbin to the PATH of ordinary mortal users. There is no security issue here, since they could always add it themselves if they actively wanted to cause harm. If you were setting up restricted-shell accounts, you would need to change PATH anyway, since bash is in the standard path, which kind of defeats the restricted shell, except as an anti-cluelessness measure :) You have both, /usr/bin and /usr/sbin in your PATH. You broke your setup so all the following comments you do doesn't change A THING to you. You can't discuss about where to put each thing if you don't use the split bin/sbin system... =/
Re: of bash and ...sbin/
Jacob Kuntz [EMAIL PROTECTED] writes: traceroute is deeper than ping. and that changes something? one cannot assume that because someone is not logged in as root, they are a casual user. Why not? Non-casual users can start these programs from sbin nonetheless (see FHS rationale for not making sbin off-limits to users), so why not make the safe assumption that the user is a casual one. Programs that have expert modes (dselect, fdisk, lynx, etc.) always start with it turned off. I think this is a good strategy. saying that traceroute is deeper than ping is like saying that ps is deeper than ls. It is, just on a different measure. This does not disprove my statement. FWIW, I feel the need for ps much more often than for traceroute. and since when do we try to hide problems, in the network or otherwise? Yes, in a way functionality is hidden: because it is not normally needed. Do you contest the need for novice vs. expert modes in general? that will only encourage people to run things as root. this is *not* a good idea. mtr is suid-root, so this is a moot point. -- Robbe
Re: of bash and ...sbin/
On Wed, Mar 22, 2000 at 08:24:42PM +0100, Robert Bihlmeyer wrote: Dylan Paul Thurston [EMAIL PROTECTED] writes: On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? traceroute is deeper than ping. It exposes things that the casual user neither sees nor cares about. Ping only measures what everybody experiences anyway: how responsive is a particular host? Without going in depth as to what traceroute and ping are (a fruitless flame war) suffice it to say that I disagree with your deeper comment. One has to draw a boundary, and on GNU systems it runs between ping and traceroute. Others do it differnently, AFAIR AIX has both in sbin. These 'boundaries' are completely arbitrary, since as pointed out earlier, Herbert Xu isn't willing to change traceroute. Perhaps we should ask Dan Quinlan? Or mtr, for that matter? That should go into sbin. I filed a wishlist item. If it is really to go in sbin, then I shall also take the suid-bit off of it, since obviously only root will be using it anyway. mtr users, relax: none of this will happen, because, first and foremost, *I* use mtr as a user. :) -- Robert Woodcock - [EMAIL PROTECTED] To the other one percent -- thanks for the passion and color! -- Jeff Bezos
of bash and ...sbin/
I like that debian's bash package has different paths for users and the superuser, but it's caused me to question ideas behind the placement of some programs in 'sbin' directories. For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Other (questionable) ones might be /usr/sbin/fbset or /usr/sbin/lpc . Which is wrong? Is it bash' assumption that only the superuser executes stuff in sbin, or that these programs should be in sbin? Essentially, by question boils down to To which packages should I apply a bug report -- bash or the others? This discussion might belong in debian-policy, depending on your answer. - chad ref'd... traceroute-nanog: /usr/sbin/traceroute lprng: /usr/sbin/lpc fbset: /usr/sbin/fbset
Re: of bash and ...sbin/
Chad Miller wrote: Which is wrong? Is it bash' assumption that only the superuser executes stuff in sbin, or that these programs should be in sbin? Essentially, by question boils down to To which packages should I apply a bug report -- bash or the others? This has been discussed (and flamed) before on this list. The current position seems to be (and I'm sure I'll be corrected if I'm wrong :): *Most* users don't use apps such as traceroute. Ones that do, should know enough to be able to put /sbin in their path. Regards, Steve
Re: of bash and ...sbin/
On Wed, Mar 22, 2000 at 10:43:54AM -0500, Chad Miller wrote: Which is wrong? Is it bash' assumption that only the superuser executes stuff in sbin, or that these programs should be in sbin? Essentially, by question boils down to To which packages should I apply a bug report -- bash or the others? This discussion might belong in debian-policy, depending on your answer. There was a _long_ thread about this some months ago. You can check debian-devel archives and the Debian Weekly News to read about it. PLEASE Don't start this again! /PLEASE Jordi
Re: of bash and ...sbin/
On Wed, Mar 22, 2000 at 10:43:54AM -0500, Chad Miller wrote: I like that debian's bash package has different paths for users and the superuser, but it's caused me to question ideas behind the placement of some programs in 'sbin' directories. For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Other (questionable) ones might be /usr/sbin/fbset or /usr/sbin/lpc . Which is wrong? Is it bash' assumption that only the superuser executes stuff in sbin, or that these programs should be in sbin? Essentially, by question boils down to To which packages should I apply a bug report -- bash or the others? This discussion might belong in debian-policy, depending on your answer. As policy states, things that pertain to system administration (and traceroute is for troubleshooting networks) is to be in /sbin or /usr/sbin. The difference between /sbin and /usr/sbin is that things that could be needed to rescue a broken system should be in /sbin (things like fsck). Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: of bash and ...sbin/
Chad Miller ([EMAIL PROTECTED]) wrote: I like that debian's bash package has different paths for users and the superuser, but it's caused me to question ideas behind the placement of some programs in 'sbin' directories. For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Other (questionable) ones might be /usr/sbin/fbset or /usr/sbin/lpc . not to mention ifconfig! having these utils in the non-root path is hardly a security risk. if anything, this is just to keep down helpdesk calls like what does MAKEDEV do? personally, since many of these commands print out usefull, non-security-risking data, i don't see any good reason to keep em out. Which is wrong? Is it bash' assumption that only the superuser executes stuff in sbin, or that these programs should be in sbin? Essentially, by question boils down to To which packages should I apply a bug report -- bash or the others? This discussion might belong in debian-policy, depending on your answer. - chad ref'd... traceroute-nanog: /usr/sbin/traceroute lprng: /usr/sbin/lpc fbset: /usr/sbin/fbset -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: of bash and ...sbin/
Ben Collins ([EMAIL PROTECTED]) wrote: As policy states, things that pertain to system administration (and traceroute is for troubleshooting networks) is to be in /sbin or /usr/sbin. The difference between /sbin and /usr/sbin is that things that could be needed to rescue a broken system should be in /sbin (things like fsck). at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: of bash and ...sbin/
On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: Ben Collins ([EMAIL PROTECTED]) wrote: As policy states, things that pertain to system administration (and traceroute is for troubleshooting networks) is to be in /sbin or /usr/sbin. The difference between /sbin and /usr/sbin is that things that could be needed to rescue a broken system should be in /sbin (things like fsck). at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? Or mtr, for that matter? --Dylan Thurston
Re: of bash and ...sbin/
Gak! I'd like to unask the question (and I do promise to have myself flogged soon) except for Jacob's sub-topic: On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? That, I think, is a good question, and hopefully has an equally good answer. I suspect we'll point to Upstream, tho. Tho I know it doesn't mean a whole lot, really, the FHS notes that... # Deciding what things go in sbin directories is simple: If a user will # need to run it, then it should go somewhere else. If it will only be run # by system administrators or as root from system management scripts, then # it should go in /sbin (or in /usr/sbin or /usr/local/sbin if the item is # not vital to system operation). and ping, traceroute, and lpc aren't for administration of _this_ system (unless you count the print queue, in in which case, /usr/bin/mailq, eh?) but it is for troubleshooting of the outside network or other machines. OTOH, i would leave ifconfig in /sbin, as it _is_ about this system, and it doesn't provide (much) information that DNS doesn't, unless there's sysadminning to be done. (There's also a huge amount of inertia that it be in /sbin/ .) (Don't reply without including the below, to help kill this thread!) NOW, having said all of that, the Inertia says leave it be! argument is _very_ compelling, at least for the near term. For woody (or woody+1), moving is likely a Good thing. That's far off, though. Potato must ship. So, sorry to have brought it up, and IAN-even-ADD. I will file no bug reports, until $release+2 . - chad
Re: of bash and ...sbin/
Chad Miller ([EMAIL PROTECTED]) wrote: OTOH, i would leave ifconfig in /sbin, as it _is_ about this system, and it doesn't provide (much) information that DNS doesn't, unless there's sysadminning to be done. (There's also a huge amount of inertia that it be in /sbin/ .) inertia aside, i use ifconfig to see if i'm dialup, and if my pcmcia card made it in. lots of programs will provide usefull information without being root. (Don't reply without including the below, to help kill this thread!) NOW, having said all of that, the Inertia says leave it be! argument is _very_ compelling, at least for the near term. For woody (or woody+1), moving is likely a Good thing. That's far off, though. Potato must ship. So, sorry to have brought it up, and IAN-even-ADD. I will file no bug reports, until $release+2 . - chad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: of bash and ...sbin/
On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: As policy states, things that pertain to system administration (and traceroute is for troubleshooting networks) is to be in /sbin or /usr/sbin. The difference between /sbin and /usr/sbin is that things that could be needed to rescue a broken system should be in /sbin (things like fsck). at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? I don't think it is, but historically it has been in /usr/sbin and Herbert Xu won't move it to a /bin-type directory because it might break existing setups. Personally, I'm not certain it's a valid reason, since we move much larger chunks of stuff to comply with the filesystem standards, and I don't see anyone complaining about that... on the contrary, in fact, people file bugs if stuff isn't in a FSSTND/FHS compliant location. Then again, a little conservativisim over moving stuff won't hurt us :) -- enJoy -*/\*- don't even try to pronounce my first name
Re: of bash and ...sbin/
Dylan Paul Thurston [EMAIL PROTECTED] writes: On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? traceroute is deeper than ping. It exposes things that the casual user neither sees nor cares about. Ping only measures what everybody experiences anyway: how responsive is a particular host? One has to draw a boundary, and on GNU systems it runs between ping and traceroute. Others do it differnently, AFAIR AIX has both in sbin. Or mtr, for that matter? That should go into sbin. I filed a wishlist item. -- Robbe
Re: of bash and ...sbin/
Robert Bihlmeyer ([EMAIL PROTECTED]) wrote: Dylan Paul Thurston [EMAIL PROTECTED] writes: On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? traceroute is deeper than ping. It exposes things that the casual user neither sees nor cares about. Ping only measures what everybody experiences anyway: how responsive is a particular host? and that changes something? one cannot assume that because someone is not logged in as root, they are a casual user. that mindset breaks with much of the way debian works. the install highly encourages you to create a normal user account. saying that traceroute is deeper than ping is like saying that ps is deeper than ls. and since when do we try to hide problems, in the network or otherwise? One has to draw a boundary, and on GNU systems it runs between ping and traceroute. Others do it differnently, AFAIR AIX has both in sbin. Or mtr, for that matter? That should go into sbin. I filed a wishlist item. that will only encourage people to run things as root. this is *not* a good idea. -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: of bash and ...sbin/
On Wed, Mar 22, 2000 at 11:50:10AM -0500, Jacob Kuntz wrote: Chad Miller ([EMAIL PROTECTED]) wrote: I like that debian's bash package has different paths for users and the superuser, but it's caused me to question ideas behind the placement of some programs in 'sbin' directories. For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Other (questionable) ones might be /usr/sbin/fbset or /usr/sbin/lpc . not to mention ifconfig! having these utils in the non-root path is hardly a security risk. if anything, this is just to keep down helpdesk calls like what does MAKEDEV do? personally, since many of these commands print out usefull, non-security-risking data, i don't see any good reason to keep em out. we've had this flamewar before, only a few months ago. just add /sbin:/usr/sbin:/usr/local/sbin to your $PATH and be done with it. it only takes a few seconds (do it in /etc/profile if you want) and it doesn't risk breaking existing scripts. many scripts (both debian scripts and local sysadmin scripts) make use of ping, traceroute, ifconfig and others in the sbin directories. it is common practice to specify the full path to sbin binaries to avoid any potential problems with the PATH being different in different contexts (e.g. login shell vs cron environment vs su or sudo environment). moving these programs to different directories will break those scripts. the minimal benefit of moving them is greatly outweighed by the damage it would cause. in short, add the sbin directories to your PATH and move on. craig -- craig sanders
Re: of bash and ...sbin/
Craig Sanders ([EMAIL PROTECTED]) wrote: in short, add the sbin directories to your PATH and move on. hey, i no more want to participate in a flamewar than the next guy. :-) i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: of bash and ...sbin/
On Wed, Mar 22, 2000 at 04:59:23PM -0500, Jacob Kuntz wrote: i don't think appending to the default path would break anything. anyone have a problem with that? nope. in fact, i routinely edit /etc/profile on new systems to do that (i pre-pend the sbin directories, not append them). it only takes a few seconds to do so i don't care much what the default is. craig -- craig sanders
