Re: using sudo (was Re: bash login for root)
On Fri, Sep 15, 2000 at 11:36:12PM -0800, Ethan Benson ([EMAIL PROTECTED]) wrote: On Fri, Sep 15, 2000 at 11:55:23PM -0700, kmself@ix.netcom.com wrote: Also, as this started off as a Debian thread somewhere/somehow, do you have any suggestions for auditing a box through dpkg / apt, including verification of packages (including checksum or signature tests where possible), detecting binaries *not* associated with packages, and/or possibly reinstalling a package over an existing instance? I believe RPM has at least some of these capabilities, not sure that DEBs do. look at the packages, debsums and cruft, debsums can check md5sums on all files (if the package came with such a list, and not all do) cruft alegedly finds files unexplained by the packaging system, i have not quite figured out how to make cruft work though, it always starts spewing off every file and directory starting from / ...and supposing debsums turns up some incorrectly checksummed packages? How do you go about correcting this? ...or do I remember reading about a reinstall w/ force option somewher the problem with debsums is its trivial for a root to tamper with /var/lib/dpkg/info/foo.md5sums. a root can also just install a custom .deb, though this will be rather apparent the way dselect/apt operate. (apt will always replace a custom package with the real one if the versions are the same, dselect shows packages not listed in the Packages.gz file as `obsolete') ideally what is needed is some tripwire like functionality integrated into dpkg. tripwire is impossibly inconvenient if you install packages often or track unstable. Oi, this would be cool. pgpOZyiI35zwo.pgp Description: PGP signature
Re: bash login for root
Bruce Richardson wrote: Debian doesn't put .bash_profile in for root. I assume you mean on a new install of debian 2.2 This is a bug in base-config (my package). See bug #66963 I hope to fix this eventually. -- see shy jo
Re: bash login for root
kmself@ix.netcom.com wrote: I'll have to think a bit before I say it's really bad. I think it's not a *good* idea It's a horrible idea. All someone has to do then is crack your user account, and they can trivially edit one of your dotfiles and the next time you su to root, they have cracked root as well. -- see shy jo
Re: bash login for root
On Mon, Sep 18, 2000 at 02:31:51PM -0700, Joey Hess ([EMAIL PROTECTED]) wrote: kmself@ix.netcom.com wrote: I'll have to think a bit before I say it's really bad. I think it's not a *good* idea It's a horrible idea. All someone has to do then is crack your user account, and they can trivially edit one of your dotfiles and the next time you su to root, they have cracked root as well. Though there are other avenues to this as well. Ethan and I have been going rounds on whether or not sudo is better than su. My contention is that sudo provides finer grained control, even when such things as sudo bash are allowed. However, in such a case, again, only user-level security need be compromised for an attacker to gain root. -- Karsten M. Self kmself@ix.netcom.com http://www.netcom.com/~kmself Evangelist, Opensales, Inc.http://www.opensales.org What part of Gestalt don't you understand? Debian GNU/Linux rocks! http://gestalt-system.sourceforge.net/K5: http://www.kuro5hin.org GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0 pgpJAkHSRuPlN.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
You should have a look a osh: $ apt-cache show osh Package: osh Priority: extra Section: shells Installed-Size: 67 Maintainer: Preston Smith [EMAIL PROTECTED] Version: 1.7-6 Depends: libc6 (= 2.1.2), libncurses5, base-files (= 2.1.6) Suggests: nvi Architecture: i386 Size: 45946 MD5sum: b53754d37bc5d58b8b8bc1c9afce772a Filename: dists/woody/main/binary-i386/shells/osh_1.7-6.deb Description: Operator's Shell The Operator Shell (Osh) is a setuid root, security enhanced, restricted shell. It allows the administrator to carefully limit the access of special commands and files to the users whose duties require their use, while at the same time automatically maintaining audit records. The configuration file for Osh contains an administrator defined access profile for each authorized user or group. The newest .deb in woody includes a white paper explaining the cocepts behind it. Looks close to what you're searching. Greetings, joachim
Re: using sudo (was Re: bash login for root)
On Fri, Sep 15, 2000 at 04:38:11PM -0800, Ethan Benson ([EMAIL PROTECTED]) wrote: On Fri, Sep 15, 2000 at 03:47:48PM -0700, kmself@ix.netcom.com wrote: But you've got zero control of commands available, and no logging of what commands are being run as root. true, but this goes back to my original comment that allowing a user account to run anything as sudo does nothing but turn it into another root account, if you want the granularity, loging and control you mention you have to take GREAT care in what you let a `sudoer' do, otherwise he can just run `sudo bash' and there goes your loging, and granularity right there. or something more insidious like this: sudo emacs M-x shell the same works with vi and loads of other editors. I'm aware of these limitations. You've got to work out acceptible policies and risks while providing the tools to get the job done. The problem I've had with direct root access is that users come on as root fromsome random IP (say, a dialup connection), and your accounting goes all to shit. With just a couple of users on a box (typical of servers I'm running), it's pretty straightforward to check to see who's doing a bunch of sudo vis or sudo bashs (and you'll find my name in both sets of greps). The question is whether or not the servers are getting fscked up in the process. Basically, it comes down to a matter of trust -- do you trust your people or don't you. The mix of sudo and full shell access means you can restrict access (barring gross malfeasance), but also track, at least to a resonable level of detail, what's going on. root's own .bash_history file is another useful resource, and when it turns up unexpectedly truncated, there are other issues at hand. Logging (root commands, logs, etc.) to a third-party box with write-once, persistant media is yet another option. It's easy to cover up tracks. It's a bit harder to cover up covering up tracks. Without the granularity of control by user and command, and logging. yes but see above. (i think we are talking about different things, i am talking about giving another admin full root privileges, where your talking about giving a admin or assistent just very partial restricted access) We're only talking partial cross-purposes. I'm looking for a tool to let me know at least when my admins are going full admin privileges, and possibly to offer limited administrative powers to more restricted users. I'm finding that the combination of prohibited root logins and sudo gives me more control than direct root logins and su. Though su is still used. Hmmm... Any way to prohibit su to root, I wonder. I think so, have to look into it. Got any ideas for systems allowing for both a fine-grained level of control *and* reasonable and flexibility for admins? Also, as this started off as a Debian thread somewhere/somehow, do you have any suggestions for auditing a box through dpkg / apt, including verification of packages (including checksum or signature tests where possible), detecting binaries *not* associated with packages, and/or possibly reinstalling a package over an existing instance? I believe RPM has at least some of these capabilities, not sure that DEBs do. -- Karsten M. Self kmself@ix.netcom.com http://www.netcom.com/~kmself Evangelist, Opensales, Inc.http://www.opensales.org What part of Gestalt don't you understand? Debian GNU/Linux rocks! http://gestalt-system.sourceforge.net/K5: http://www.kuro5hin.org GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0 pgpY4M0nphHFM.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
On Fri, Sep 15, 2000 at 11:55:23PM -0700, kmself@ix.netcom.com wrote: I'm aware of these limitations. You've got to work out acceptible policies and risks while providing the tools to get the job done. The problem I've had with direct root access is that users come on as root fromsome random IP (say, a dialup connection), and your accounting goes all to shit. yes of course, that is why all my machines have this line in thier sshd_config: PermitRootLogin no then there is no more direct root login except on the console. as it should be. With just a couple of users on a box (typical of servers I'm running), it's pretty straightforward to check to see who's doing a bunch of sudo vis or sudo bashs (and you'll find my name in both sets of greps). [EMAIL PROTECTED] eb]$ tail -1 /var/log/sulog SU 09/15 03:09 + tty2 eb-root [EMAIL PROTECTED] eb]$ The question is whether or not the servers are getting fscked up in the process. quite true. Basically, it comes down to a matter of trust -- do you trust your people or don't you. The mix of sudo and full shell access means you can restrict access (barring gross malfeasance), but also track, at least to a resonable level of detail, what's going on. root's own .bash_history file is another useful resource, and when it turns up unexpectedly truncated, there are other issues at hand. Logging (root commands, logs, etc.) to a third-party box with write-once, persistant media is yet another option. yes but not really trivial to implement. sudo does nice logging, but its totally defeated when someone runs sudo bash. (you still have .bash_history but its hard to track things there to an individual) It's easy to cover up tracks. It's a bit harder to cover up covering up tracks. perhaps We're only talking partial cross-purposes. I'm looking for a tool to let me know at least when my admins are going full admin privileges, and possibly to offer limited administrative powers to more restricted users. I'm finding that the combination of prohibited root logins and sudo gives me more control than direct root logins and su. Though su is still used. Hmmm... Any way to prohibit su to root, I wonder. I think so, have to look into it. add this line to your /etc/pam.d/su file: authrequisite pam_wheel.so group=wheel debug [EMAIL PROTECTED] ~]$ id uid=1002(erb) gid=1002(erb) groups=1002(erb) [EMAIL PROTECTED] ~]$ su su: Permission denied Sorry. [EMAIL PROTECTED] ~]$ Got any ideas for systems allowing for both a fine-grained level of control *and* reasonable and flexibility for admins? capabilities? Also, as this started off as a Debian thread somewhere/somehow, do you have any suggestions for auditing a box through dpkg / apt, including verification of packages (including checksum or signature tests where possible), detecting binaries *not* associated with packages, and/or possibly reinstalling a package over an existing instance? I believe RPM has at least some of these capabilities, not sure that DEBs do. look at the packages, debsums and cruft, debsums can check md5sums on all files (if the package came with such a list, and not all do) cruft alegedly finds files unexplained by the packaging system, i have not quite figured out how to make cruft work though, it always starts spewing off every file and directory starting from / the problem with debsums is its trivial for a root to tamper with /var/lib/dpkg/info/foo.md5sums. a root can also just install a custom .deb, though this will be rather apparent the way dselect/apt operate. (apt will always replace a custom package with the real one if the versions are the same, dselect shows packages not listed in the Packages.gz file as `obsolete') ideally what is needed is some tripwire like functionality integrated into dpkg. tripwire is impossibly inconvenient if you install packages often or track unstable. really though if you have a hostile (or incompetant) root you can't get rid of your 120% screwed from the starting gate and there is not a damn thing you can do about it. (especially if your not the one who can get rid of them rather the oposite) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpzegimRQuDA.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
On Thu, Sep 14, 2000 at 03:11:42PM -0800, Ethan Benson ([EMAIL PROTECTED]) wrote: On Thu, Sep 14, 2000 at 12:31:27PM -0700, kmself@ix.netcom.com wrote: you could also accomplish this by creating mulitple uid=0 accounts with different passwords, at least that way if Tim gets his user password stolen its not an automatic root compromise. But you've got zero control of commands available, and no logging of what commands are being run as root. also if Nate was really evil/disgrunteled he may have installed a rootkit or backdoor before he was canned. in which case sudo or not your screwed anyway ;-) Modulo: if you suspect this up front, you can throttle his access in an instant, *without* disrupting the rest of the team. In no case do you have to worry about poor old Bob, who's just a dumb luser. Maybe you want to give him limited access to the print queue -- see the sudo docs for info on how to do this. Use of sudo also allows denying *all* remote root access. Hit the system as a normal user first, then go root. so does PermitRootLogin no and pam_wheel. Without the granularity of control by user and command, and logging. -- Karsten M. Self kmself@ix.netcom.com http://www.netcom.com/~kmself Evangelist, Opensales, Inc.http://www.opensales.org What part of Gestalt don't you understand? Debian GNU/Linux rocks! http://gestalt-system.sourceforge.net/K5: http://www.kuro5hin.org GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0 pgpemH3IqxXAK.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
On Fri, Sep 15, 2000 at 03:47:48PM -0700, kmself@ix.netcom.com wrote: But you've got zero control of commands available, and no logging of what commands are being run as root. true, but this goes back to my original comment that allowing a user account to run anything as sudo does nothing but turn it into another root account, if you want the granularity, loging and control you mention you have to take GREAT care in what you let a `sudoer' do, otherwise he can just run `sudo bash' and there goes your loging, and granularity right there. or something more insidious like this: sudo emacs M-x shell the same works with vi and loads of other editors. even something as seemingly simple as `sudo make install' all one would have to do is create the following Makefile anywhere and run `sudo make install' to get a suid rootshell: install: install -o root -g evil -m 4750 /bin/bash /dev/.sh also if Nate was really evil/disgrunteled he may have installed a rootkit or backdoor before he was canned. in which case sudo or not your screwed anyway ;-) Modulo: if you suspect this up front, you can throttle his access in an instant, *without* disrupting the rest of the team. assuming he didn't already get the chance to install a backdoor. in which case its reinstall time. Without the granularity of control by user and command, and logging. yes but see above. (i think we are talking about different things, i am talking about giving another admin full root privileges, where your talking about giving a admin or assistent just very partial restricted access) -- Ethan Benson http://www.alaska.net/~erbenson/ pgp1ZzyvDTXMQ.pgp Description: PGP signature
Re: bash login for root
Bob Nielsen [EMAIL PROTECTED] writes: I use sudo, logged in as a regular user. It's generally considered a security risk to be logged in as root, and a bit less of a risk to use sudo or fakeroot. Aha. I only started using sudo seriously about an hour ago. Funny, but 'sudo echo $PATH' gives the $PATH of the user, but 'sudo whoami' says root. Hm, that's not *that* surprising, is it? The first one says, run the 'echo' command as if you were root (presumably the $PATH part gets expanded before the call to sudo). The second one says, run the 'whoami' command is if you were root, and works as expected. sudo does access the binaries in /usr/sbin, which are not in the user's $PATH. Really? My PATH is something like this: /home/krzys/shell:.:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games (Come to think of it this makes no sense, neither /etc/profile nor ~/.bashrc set the path quite like this, but anyway.) Is it a bad idea to have /usr/sbin/ in one's path? For things like /sbin/halt I give the following permissions: -rwsr-xr--1 root admin7796 Jun 25 05:23 halt* -chris
Re: bash login for root
On Wed, Sep 13, 2000 at 09:23:30PM -0700, Krzys Majewski wrote: Bob Nielsen [EMAIL PROTECTED] writes: I use sudo, logged in as a regular user. It's generally considered a security risk to be logged in as root, and a bit less of a risk to use sudo or fakeroot. Aha. I only started using sudo seriously about an hour ago. Funny, but 'sudo echo $PATH' gives the $PATH of the user, but 'sudo whoami' says root. Hm, that's not *that* surprising, is it? The first one says, run the 'echo' command as if you were root (presumably the $PATH part gets expanded before the call to sudo). The second one says, run the 'whoami' command is if you were root, and works as expected. I see. sudo does access the binaries in /usr/sbin, which are not in the user's $PATH. Really? My PATH is something like this: /home/krzys/shell:.:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games (Come to think of it this makes no sense, neither /etc/profile nor ~/.bashrc set the path quite like this, but anyway.) Is it a bad idea to have /usr/sbin/ in one's path? For things like /sbin/halt I give the following permissions: -rwsr-xr--1 root admin7796 Jun 25 05:23 halt* That will work. I don't think the sbin directories are in user paths by default. Of course, the considerations here are probably based on what a multi-user system would use. -- Bob Nielsen, N7XY [EMAIL PROTECTED] Bainbridge Island, WA http://www.oz.net/~nielsen
Re: bash login for root
I'll have to think a bit before I say it's really bad. I think it's not a *good* idea, and I almost certainly wouldn't do that. Immediate problems: - If you've created seperate partitions for / and /home, you won't have a root home directory when mounting just the root partition. This could be somewhat problematic. - root and normal users typically don't have the same needs for configurations -- your root .bashrc and path should typically differ from your standard user account. - user accounts are more likely to accumulate cruft which could be annoying, or harmful, used by root. Or simply annoying when root changes permissions and/or ownership. - /root is owned by the distribution, IIRC. $HOME for a nonprivileged user is not. I'd split the home directories. On Wed, Sep 13, 2000 at 08:52:20PM -0700, Krzys Majewski ([EMAIL PROTECTED]) wrote: My /root/ is a symlink to /home/krzys. Since it's been this way for about a hundred years, I figure it's about time to ask the question: is it a really bad idea? -chris Nate Bargmann [EMAIL PROTECTED] writes: On Wed, Sep 13, 2000 at 12:13:59AM +0100, Bruce Richardson wrote: Debian doesn't put .bash_profile in for root. I want to put one in to extend root's path. Putting my own .bash_profile means putting in the path in full, since bash doesn't do roots path if there's a bash_profile. Is there anything else that would be missed out if I were to put in a .bash_profile? Try /root/.profile instead. For some reason Bash looks for it in the /root directory. -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- Karsten M. Self kmself@ix.netcom.com http://www.netcom.com/~kmself Evangelist, Opensales, Inc.http://www.opensales.org What part of Gestalt don't you understand? Debian GNU/Linux rocks! http://gestalt-system.sourceforge.net/K5: http://www.kuro5hin.org GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0 pgpWrHGIG4aGv.pgp Description: PGP signature
Re: bash login for root
On Wed, Sep 13, 2000 at 08:56:32PM -0700, Bob Nielsen wrote: I use sudo, logged in as a regular user. It's generally considered a security risk to be logged in as root, and a bit less of a risk to use sudo or fakeroot. well it depends on how you setup sudo, IMO letting your non-privileged account run anything as root via sudo is a bad idea. it essenially turns your non-privileged account password into the root password. sudo bash yeck. sudo is nice for stuff that needs root privileges but by itself cannot be exploited to do anything evil, like run a shell. Funny, but 'sudo echo $PATH' gives the $PATH of the user, but 'sudo whoami' says root. sudo does access the binaries in /usr/sbin, which are not in the user's $PATH. sudo uses a hard coded PATH to locate binaries it does not use your or root's PATH. (it never loads root's environment at all). -- Ethan Benson http://www.alaska.net/~erbenson/ pgpipRrjIIeni.pgp Description: PGP signature
Re: bash login for root
On Wed, Sep 13, 2000 at 09:23:30PM -0700, Krzys Majewski wrote: Really? My PATH is something like this: then you changed it, this is not default. /home/krzys/shell:.:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games ^ that is VERY bad, you should not even have . in your path, but if you insist put it LAST. why? say you do this: cd /tmp ls -l and someone put a little shell script in /tmp called ls that looks like this: #! /bin/sh rm -rf ~ exec ls $@ now class tell me what will happen when your run ls -l when your cwd is /tmp with the above PATH? (Come to think of it this makes no sense, neither /etc/profile nor ~/.bashrc set the path quite like this, but anyway.) Is it a bad idea check ~/.bash_profile. you had to have done this as i have never seen any system set a path like that by default. (not even redhat which is famous for bogus PATHs) to have /usr/sbin/ in one's path? For things like /sbin/halt I give the following permissions: -rwsr-xr--1 root admin7796 Jun 25 05:23 halt* you have a wierd system, i have see something like that on OpenBSD but not in GNU/Linux. as for sbin in your PATH, no its not really a problem, there is no security issues with it since you can run anything regardless of the PATH, observe: [EMAIL PROTECTED] eb]$ shutdown now bash: shutdown: command not found [EMAIL PROTECTED] eb]$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/home/eb/bin [EMAIL PROTECTED] eb]$ /sbin/shutdown now shutdown: must be root. [EMAIL PROTECTED] eb]$ the sbin thing is a religious issue that has been starting flamewars for eternity. the idea now (accoring to FHS) is to put sysadmin stuff that is largely useless to a ordinary user in /sbin or /usr/sbin and leave the sbins out of the user's PATH. its all a matter of preference, personally i like the distinction (if the system is organized properly which debian largely is. OpenBSD is largely not, so on OpenBSD i tend to just leave sbin in my PATH) -- Ethan Benson http://www.alaska.net/~erbenson/ pgpuFLSDqVYcD.pgp Description: PGP signature
Re: bash login for root
On Wed, Sep 13, 2000 at 10:54:17PM -0500, Will Trillich wrote: in my thinking, that reason would be: home directory for user 'root' is /root. :) You caught me! What I meant was that Bash looks for .profile in /root instead of .bash_profile as with normal users. Yes, I'm well aware /root is the home directory for the 'root' user. Doh! - Nate -- Wireless | Amateur Radio Station N0NB | None can love freedom Internet | [EMAIL PROTECTED] | heartily, but good Location | Wichita, Kansas USA EM17hs | men; the rest love not Wichita area exams; ham radio; Linux info @ | freedom, but license. http://www.qsl.net/n0nb/ | -- John Milton
Re: bash login for root
On Thu, Sep 14, 2000 at 07:38:27AM -0500, Nate Bargmann wrote: On Wed, Sep 13, 2000 at 10:54:17PM -0500, Will Trillich wrote: in my thinking, that reason would be: home directory for user 'root' is /root. :) You caught me! What I meant was that Bash looks for .profile in /root instead of .bash_profile as with normal users. Yes, I'm well aware /root is the home directory for the 'root' user. Doh! actually i think bash looks for ~/.profile first and ~/.bash_profile last. and iirc only uses one, not both. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp2dX8S0Fny4.pgp Description: PGP signature
Re: bash login for root
From: Ethan Benson [EMAIL PROTECTED] actually i think bash looks for ~/.profile first and ~/.bash_profile last. and iirc only uses one, not both. Not according to the man page: Login shells: On login (subject to the -noprofile option): if /etc/profile exists, source it. if ~/.bash_profile exists, source it, else if ~/.bash_login exists, source it, else if ~/.profile exists, source it. My work box (Red Hat) happily uses .bash_profile but my home box (Debian) doesn't - I'll check my home box tonight. Thought occurs: maybe Debian has /bin/sh for Root and not /bin/bash. When called as sh, bash only does /etc/profile and ~/.profile -- Bruce
Re: bash login for root
On Thu, Sep 14, 2000 at 07:38:27AM -0500, Nate Bargmann wrote: On Wed, Sep 13, 2000 at 10:54:17PM -0500, Will Trillich wrote: in my thinking, that reason would be: home directory for user 'root' is /root. :) You caught me! What I meant was that Bash looks for .profile in /root instead of .bash_profile as with normal users. Yes, I'm well aware /root is the home directory for the 'root' user. Doh! Ooops. True. Why does bash difference this files ? Thanks. - Nate -- Wireless | Amateur Radio Station N0NB | None can love freedom Internet | [EMAIL PROTECTED] | heartily, but good Location | Wichita, Kansas USA EM17hs | men; the rest love not Wichita area exams; ham radio; Linux info @ | freedom, but license. http://www.qsl.net/n0nb/ | -- John Milton -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- Juli-Manel Merino Vidal Email: [EMAIL PROTECTED] Homepage: http://jmmv.cjb.net
Re: bash login for root
[EMAIL PROTECTED] said: Thought occurs: maybe Debian has /bin/sh for Root and not /bin/bash. When called as sh, bash only does /etc/profile and ~/.profile Nope, that's not it: root:x:0:0:root:/root:/bin/bash ^ -- Two words: Windows survives. - Craig Mundie, Microsoft senior strategist So does syphillis. Good thing we have penicillin. - Matthew Alton Geek Code 3.1: GCS d- s+: a- C++ UL++$ P L+++ E- W--(++) N+ o+ !K w---$ O M- V? PS+ PE Y+ PGP t 5++ X+ R++ tv b+ DI D G e* h+ r++ y+
Re: bash login for root
-- From: Julio Merino [EMAIL PROTECTED] You caught me! What I meant was that Bash looks for .profile in /root instead of .bash_profile as with normal users. Yes, I'm well aware /root is the home directory for the 'root' user. Doh! Ooops. True. Why does bash difference this files ? It doesn't. If I create /root/.bash_profile, bash uses it. BUT root then gets a user path, not the special root path. Now, on my RH machine, I have this in .bash_profile: PATH=$HOME/bin:$PATH export PATH This works fine and I get the root path (all the sbins etc.) plus /root/bin. If I do the same thing on Debian, I get the user path plus /root/bin. This is what perplexes me. -- Bruce
Re: bash login for root
On Thu, Sep 14, 2000 at 04:45:27AM -0800, Ethan Benson wrote: actually i think bash looks for ~/.profile first and ~/.bash_profile last. and iirc only uses one, not both. Call me Mr. Stupid. There's a /root/.profile there. %-X -- Bruce A problem shared gives the consolation that someone else is now feeling as miserable as you.
Re: bash login for root
On Thu, 14 Sep 2000 [EMAIL PROTECTED] wrote: From: Julio Merino [EMAIL PROTECTED] It doesn't. If I create /root/.bash_profile, bash uses it. BUT root then gets a user path, not the special root path. Now, on my RH machine, I have this in .bash_profile: PATH=$HOME/bin:$PATH export PATH This works fine and I get the root path (all the sbins etc.) plus /root/bin. If I do the same thing on Debian, I get the user path plus /root/bin. This is what perplexes me. So, PATH is set to include the sbin dirs prior to bash seeing these lines on the RH box but not on the Debian box. Does the RH box's /root/.bash_profile contain . ~/.bashrc (or equivalent)? and if so, does .bashrc set or alter PATH? You have really only told us the symptoms and a few fragments of bash's startup scripts, we need to see everything bash sees. i.e., every line containing PATH in /etc/profile, /root/.bash_profile, and anything they source - in the order bash sees them. I suspect that if you go through this process it will become obvious as to why things are not working out the way you expect. A root login on my box goes through the following: PATH set to something suitable for a user in /etc/profile; reset to a standard root's path in .bashrc, which is sourced from .bash_profile; and finally prepended with ~/bin in .bash_profile. later, Bruce
using sudo (was Re: bash login for root)
On Wed, Sep 13, 2000 at 10:23:14PM -0800, Ethan Benson ([EMAIL PROTECTED]) wrote: On Wed, Sep 13, 2000 at 08:56:32PM -0700, Bob Nielsen wrote: I use sudo, logged in as a regular user. It's generally considered a security risk to be logged in as root, and a bit less of a risk to use sudo or fakeroot. well it depends on how you setup sudo, IMO letting your non-privileged account run anything as root via sudo is a bad idea. it essenially turns your non-privileged account password into the root password. sudo bash yeck. The advantage in a multiuser environment is that you providing (and controlling) root access at the user level rather than at the system level. Eg, Tim, Bob, Alice, and Nate have access to a system. Tim, Alice, and Nate are admins. Nate is canned for violating company SOP. If Tim, Alice, and Nate shared the root password, you need to: - Change the root password. - Tell Tim and Alice If root access was provided via sudo: - Remove Nate from the /etc/sudoers file. In no case do you have to worry about poor old Bob, who's just a dumb luser. Maybe you want to give him limited access to the print queue -- see the sudo docs for info on how to do this. Use of sudo also allows denying *all* remote root access. Hit the system as a normal user first, then go root. Ideally, the root account password is simply not well known, and console admin is done only when absolutely required, with password being created at this time or unsealed as needed. -- Karsten M. Self kmself@ix.netcom.com http://www.netcom.com/~kmself Evangelist, Opensales, Inc.http://www.opensales.org What part of Gestalt don't you understand? Debian GNU/Linux rocks! http://gestalt-system.sourceforge.net/K5: http://www.kuro5hin.org GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0 pgpaOQu5RNml6.pgp Description: PGP signature
Re: using sudo (was Re: bash login for root)
On Thu, Sep 14, 2000 at 12:31:27PM -0700, kmself@ix.netcom.com wrote: The advantage in a multiuser environment is that you providing (and controlling) root access at the user level rather than at the system level. Eg, Tim, Bob, Alice, and Nate have access to a system. Tim, Alice, and Nate are admins. Nate is canned for violating company SOP. If Tim, Alice, and Nate shared the root password, you need to: - Change the root password. - Tell Tim and Alice If root access was provided via sudo: - Remove Nate from the /etc/sudoers file. you could also accomplish this by creating mulitple uid=0 accounts with different passwords, at least that way if Tim gets his user password stolen its not an automatic root compromise. also if Nate was really evil/disgrunteled he may have installed a rootkit or backdoor before he was canned. in which case sudo or not your screwed anyway ;-) In no case do you have to worry about poor old Bob, who's just a dumb luser. Maybe you want to give him limited access to the print queue -- see the sudo docs for info on how to do this. Use of sudo also allows denying *all* remote root access. Hit the system as a normal user first, then go root. so does PermitRootLogin no and pam_wheel. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpRoT10i5jG0.pgp Description: PGP signature
bash login for root
Debian doesn't put .bash_profile in for root. I want to put one in to extend root's path. Putting my own .bash_profile means putting in the path in full, since bash doesn't do roots path if there's a bash_profile. Is there anything else that would be missed out if I were to put in a .bash_profile? -- Bruce The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++. -- Richard P. Gabriel
Re: bash login for root
I don't log in as root very often, but never had any problems having a .bash_profile in /root. On Wed, Sep 13, 2000 at 12:13:59AM +0100, Bruce Richardson wrote: Debian doesn't put .bash_profile in for root. I want to put one in to extend root's path. Putting my own .bash_profile means putting in the path in full, since bash doesn't do roots path if there's a bash_profile. Is there anything else that would be missed out if I were to put in a .bash_profile? -- Bob Nielsen, N7XY [EMAIL PROTECTED] Bainbridge Island, WA http://www.oz.net/~nielsen
Re: bash login for root
Bob Nielsen [EMAIL PROTECTED] writes: I don't log in as root very often, but never had any problems having a .bash_profile in /root. OK sounds like you're telling us something here. You're on the list, so obviously you tweak your debian box from time to time. But you don't log in as root very often. How do you do it?? I'm logged in to xdm as me but I've got a root xterm going about half the time.. -chris
Re: bash login for root
On Wed, Sep 13, 2000 at 12:13:59AM +0100, Bruce Richardson wrote: Debian doesn't put .bash_profile in for root. I want to put one in to extend root's path. Putting my own .bash_profile means putting in the path in full, since bash doesn't do roots path if there's a bash_profile. Is there anything else that would be missed out if I were to put in a .bash_profile? Try /root/.profile instead. For some reason Bash looks for it in the /root directory. - Nate -- Wireless | Amateur Radio Station N0NB | None can love freedom Internet | [EMAIL PROTECTED] | heartily, but good Location | Wichita, Kansas USA EM17hs | men; the rest love not Wichita area exams; ham radio; Linux info @ | freedom, but license. http://www.qsl.net/n0nb/ | -- John Milton
Re: bash login for root
On Wed, Sep 13, 2000 at 08:07:46PM -0700, Krzys Majewski wrote: Bob Nielsen [EMAIL PROTECTED] writes: I don't log in as root very often, but never had any problems having a .bash_profile in /root. OK sounds like you're telling us something here. You're on the list, so obviously you tweak your debian box from time to time. But you don't log in as root very often. How do you do it?? I'm logged in to xdm as me but I've got a root xterm going about half the time.. when i was setting up my box i had a root shell suspended somewhere nearly all the time. not good security, but until i gained confidence that it was running the way i wanted, i needed root access to munge this here and frob that there. these days, i only have a root shell running 40% of the time. :) most of your 'use-the-computer' work otta be done in a user shell. use root only for system maintenance and updates!
Re: bash login for root
My /root/ is a symlink to /home/krzys. Since it's been this way for about a hundred years, I figure it's about time to ask the question: is it a really bad idea? -chris Nate Bargmann [EMAIL PROTECTED] writes: On Wed, Sep 13, 2000 at 12:13:59AM +0100, Bruce Richardson wrote: Debian doesn't put .bash_profile in for root. I want to put one in to extend root's path. Putting my own .bash_profile means putting in the path in full, since bash doesn't do roots path if there's a bash_profile. Is there anything else that would be missed out if I were to put in a .bash_profile? Try /root/.profile instead. For some reason Bash looks for it in the /root directory.
Re: bash login for root
On Wed, Sep 13, 2000 at 10:27:55PM -0500, Nate Bargmann wrote: On Wed, Sep 13, 2000 at 12:13:59AM +0100, Bruce Richardson wrote: Debian doesn't put .bash_profile in for root. I want to put one in to extend root's path. Putting my own .bash_profile means putting in the path in full, since bash doesn't do roots path if there's a bash_profile. Is there anything else that would be missed out if I were to put in a .bash_profile? Try /root/.profile instead. For some reason Bash looks for it in the /root directory. - Nate in my thinking, that reason would be: home directory for user 'root' is /root. :) i.e. % echo ~root /root % grep root /etc/passwd root:x:0:0:root:/root:/bin/sh (field 6 == /root) i think this is because when in single-user mode, logged in as root for serious maintenance (kahuna backups, for example) with just the / partition mounted, user root isn't left stranded.
Re: bash login for root
I use sudo, logged in as a regular user. It's generally considered a security risk to be logged in as root, and a bit less of a risk to use sudo or fakeroot. Funny, but 'sudo echo $PATH' gives the $PATH of the user, but 'sudo whoami' says root. sudo does access the binaries in /usr/sbin, which are not in the user's $PATH. Bob On Wed, Sep 13, 2000 at 08:07:46PM -0700, Krzys Majewski wrote: Bob Nielsen [EMAIL PROTECTED] writes: I don't log in as root very often, but never had any problems having a .bash_profile in /root. OK sounds like you're telling us something here. You're on the list, so obviously you tweak your debian box from time to time. But you don't log in as root very often. How do you do it?? I'm logged in to xdm as me but I've got a root xterm going about half the time.. -chris -- Bob Nielsen, N7XY [EMAIL PROTECTED] Bainbridge Island, WA http://www.oz.net/~nielsen
