Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
hi, I think had a similar problem a while back. I'm used to using fdisk to see disk space usage, but was very surprised that my "fdisk" command didn't work. Which is why I switched to df.
if whereis fdisk, man fdisk do not work, then it's probably not installed. Try typing "aptitude install fdisk"
The shell's PATH is likely not setup to find fdisk. Type:
locate fdisk
and you'll find it.
When you become root, the PATH is changed, and paths that contain privileged commands are added to PATH, so root can run fdisk without trouble finding its location. But your PATH does not include paths such as /sbin and /usr/sbin.
For most disto's sudo is configured so that you need to include the full path to a root command anyway. This can prevent and alias or bogus command in your regular PATH from being executed by mistake. As already stated, if you can't find a command, use the locate command to find it. I will preced the command name with 'bin/' to filter out non executables matching the pattern.
There are no such restrictions on my distros. What restrictions are enabled on yours?
Maybe you don't have things setup properly.
Code:
excerpt from 'man sudo'
SUDO(8) MAINTENANCE COMMANDS SUDO(8)
NAME
sudo, sudoedit - execute a command as another user
SYNOPSIS
sudo -K | -L | -V | -h | -k | -l | -v
sudo [-HPSb] [-a auth_type] [-c class|-] [-p prompt] [-u user-
name|#uid] {-e file [...] | -i | -s | command}
sudoedit [-S] [-a auth_type] [-p prompt] [-u username|#uid] file
[...]
DESCRIPTION
sudo allows a permitted user to execute a command as the superuser
or another user, as specified in the sudoers file. The real and
effective uid and gid are set to match those of the target user as
specified in the passwd file and the group vector is initialized
based on the group file (unless the -P option was specified). If
the invoking user is root or if the target user is the same as the
invoking user, no password is required. Otherwise, sudo requires
that users authenticate themselves with a password by default
(NOTE: in the default configuration this is the user's password,
not the root password). Once a user has been authenticated, a
timestamp is updated and the user may then use sudo without a pass-
word for a short period of time (5 minutes unless overridden in
sudoers).
When invoked as sudoedit, the -e option (described below), is
implied.
sudo determines who is an authorized user by consulting the file
/etc/sudoers. By giving sudo the -v flag a user can update the
time stamp without running a command. The password prompt itself
will also time out if the user's password is not entered within 5
minutes (unless overridden via sudoers).
If a user who is not listed in the sudoers file tries to run a com-
mand via sudo, mail is sent to the proper authorities, as defined
at configure time or in the sudoers file (defaults to root). Note
that the mail will not be sent if an unauthorized user tries to run
sudo with the -l or -v flags. This allows users to determine for
themselves whether or not they are allowed to use sudo.
If sudo is run by root and the SUDO_USER environment variable is
set, sudo will use this value to determine who the actual user is.
This can be used by a user to log commands through sudo even when a
root shell has been invoked. It also allows the -e flag to remain
useful even when being run via a sudo-run script or program. Note
however, that the sudoers lookup is still done for root, not the
user specified by SUDO_USER.
sudo can log both successful and unsuccessful attempts (as well as
errors) to syslog(3), a log file, or both. By default sudo will
log via syslog(3) but this is changeable at configure time or via
the sudoers file.
Code:
excerpt 'man sudoers';
SUDOERS(5) MAINTENANCE COMMANDS SUDOERS(5)
NAME
sudoers - list of which users may execute what
DESCRIPTION
The sudoers file is composed of two types of entries: aliases
(basically variables) and user specifications (which specify who
may run what).
When multiple entries match for a user, they are applied in order.
Where there are conflicting values, the last match is used (which
is not necessarily the most specific match).
If you read the mans' for the commands then you should be able set things right.
All he's saying is that he doen't need to put in the full path to a root command when he uses sudo. I've got a sneaking suspicion, having seen a few of Mr C's posts that he can read a man page.
onebuck - your claim is that sudo is configured to prevent non-full patch execution of commands (eg. relative paths). This isn't the case, and you haven't proven that it is otherwise.
While sudo can be compiled to setup a SECURE_PATH, this is only a starting point. Sudo can also be called with -i, that simulates a login of the target user. Typically, most root PATH's contain /sbin and /usr/sbin, and sometimes /usr/local/sbin. So this also counter-indicates your claim.
Sudo can also force the "." and "" components of a PATH to the end of the command lookup process (by moving dot and the null path to the end of PATH).
It can be considered a good security practice to use full path names to certain commands. And for that matter, this also goes for sudo itself as well.
All he's saying is that he doen't need to put in the full path to a root command when he uses sudo. I've got a sneaking suspicion, having seen a few of Mr C's posts that he can read a man page.
Not to get into a flame war but you would be surprised as to who does read a 'man page'.
I've read some of his posts. I posted the information not just for 'Mr C' but to the original poster. The mans are a great resource that everyone should learn to use.
onebuck - your claim is that sudo is configured to prevent non-full patch execution of commands (eg. relative paths). This isn't the case, and you haven't proven that it is otherwise.
While sudo can be compiled to setup a SECURE_PATH, this is only a starting point. Sudo can also be called with -i, that simulates a login of the target user. Typically, most root PATH's contain /sbin and /usr/sbin, and sometimes /usr/local/sbin. So this also counter-indicates your claim.
Sudo can also force the "." and "" components of a PATH to the end of the command lookup process (by moving dot and the null path to the end of PATH).
It can be considered a good security practice to use full path names to certain commands. And for that matter, this also goes for sudo itself as well.
If you setup the sudoers file then things can be controlled. I have no argument with your statement. I see no counter claim being made. You can secure the system with the config files.
As I stated before, the use of 'sudo -i';
Code:
excerpt from 'man sudo'
-i The -i (simulate initial login) option runs the shell specified
in the passwd(5) entry of the user that the command is being
run as. The command name argument given to the shell begins
with a - to tell the shell to run as a login shell. sudo
attempts to change to that user's home directory before running
the shell. It also initializes the environment, leaving TERM
unchanged, setting HOME, SHELL, USER, LOGNAME, and PATH, and
unsetting all other environment variables. Note that because
the shell to use is determined before the sudoers file is
parsed, a runas_default setting in sudoers will specify the
user to run the shell as but will not affect which shell is
actually run.
I prefer a closed and controlled system. I limit superuser rights to myself. So my 'su' & 'sudo' is secure and no one else will get rights. You can setup as you like, it's your system. I have less problems with not allowing others superuser rights.
This debate isn't about your configuration choice, or mine. You made a false claim: "For most disto's sudo is configured so that you need to include the full path to a root command anyway."
What sudo configuration option are you claiming to find in most distros!?
Not to get into a flame war but you would be surprised as to who does read a 'man page'.
I've read some of his posts. I posted the information not just for 'Mr C' but to the original poster. The mans are a great resource that everyone should learn to use.
No offence taken by me, and I fully agree that it would be good if people started with man pages (even though soem are absolute crap and soem are as complex as all heck)
I made no false claims! You are reading into my posts. I have been presenting that the distro can be secured with proper configuration and setup. Show me in the thread where I made the claims that you state or counter claims as you put it.
I really don't think we are looking at the problem from the same perspective. I'm not making claims as you seem to insinuate but presenting the information to configure. I'm through with this thread since you seem I want to debate and I am making claims that I did not. You cannot look at the setup of any distributions holistically since each is setup to meet the needs of the administrator as he/she sees the need for the security setup. Some forks tend to follow the original security setup but not always.
I quoted your statement. It is there in black and white. Futhermore, you state: "This can prevent and [sic] alias or bogus command in your regular PATH from being executed by mistake". Since aliases do not survive into a forked process, no alias can present an risk. Aliases only exist in your current shell, and must be recreated anew in each new shell. And finally, if you have a "bogus" command in some directory listed in your own PATH, sudo does not protect against that command from running in default sudo installations on various distributions.
I'll put it another way - sudo is *not* configured so that you need to enter full paths to commands, nor is it configured by default in "most distros" to offer any of the protections you claim.
I personally don't care what you chose to believe. I prefer to explain to user's how the system *really* works, and not provide cock-n-bull, FUD, and misinformation.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.