Hot answers tagged

5

No, vim is not set user id (that is, it will not change effective userid). running a command line from vim will give you a shell (that is the word) as user2. By the way, to edit the file you must either be user user3 belong to group user2, merely being user2 is not enough. There used to be a bug in redhat 4.x (or still is) when running visudo, which ...


3

The command line history for bash shell sessions are stored in the ~/.bash_history file. If this file does not exist, it is created with no read permissions for other users. You may change the number of commands that bash saves into this file by setting the HISTFILESIZE environment variable. Setting it to zero will truncate the history file to zero size. ...


3

If we look at the source for (a version of) i3lock, we can see it determines the user whose password is required by doing getuid(). So setting the environment variable USER has no effect, and you will need to su or sudo as that user instead.


3

Yes Yes Yes It depends, complex program (database, tomcat like web server) do, smaller (gif generator) don't. It depends, if no set user id, program will run as clicking user. root mostly, some as www (if you have a web server), some as bin, mail.


3

It looks like that's actually the username. Try checking the passwd file, and you might find that somebody tried to comment out a line: grep owner /etc/passwd If you find that there is a line starting with #, then if there is another line which doesn't have it, you may want to remove the line with the #. Otherwise, you may just want to remove the #. That ...


2

Just figured out the problem. When you giving privileges from other then the root user, then you need to specify user at the sudo command. See below example: This command run by cat and it works. sudo -u dog vim /home/dog/test.txt


2

As root edit /etc/sudoers and place the following line: youruser ALL=(ALL) NOPASSWD:ALL after # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL In this way you will be capable to execute all commands that require sudo privileges passwordless. In order to use sudo and be prompted for a password you need to remove ...


2

There are many ways to hide your command history, but it's a bad idea to turn off history altogether as it is very useful. Here are three good ways to turn it off temporarily. Quickest solution: Type unset HISTFILE That will prevent all commands run in the current login session from getting saved to the .bash_history file when you logout. Note that ...


2

The best and easiest thing you can do is to add groups to each of your users, i.e. modifying your users! This task can be done by using usermod command. Read more here. Be aware that -g option is for user's new initial group (i.e. Primary) while -G option is a list of supplementary groups which the user can be also a member of. You can get more information ...


2

By saying you're in user2's shell you imply you've been logged in as user2, the command whoami or echo $LOGNAME will let you know the same. Whatever commands you are firing in the terminal are considered to be fired by the logged-in user, except for those through sudo. The coloumn names in an output of ls is as below, for you reference. The Fourth field is ...


1

First, try changing AllowUser userName in the /etc/sshd_config file on your WD My Book to AllowUsers root admin userName to see if that resolves the issue. Also, check the contents of /etc/passwd and make sure that the entry for userName doesn't include /user/sbin/nologin, but instead something like /bin/bash. For instance, the entry for the admin account ...


1

This is a bare minimum script to get the job done. It makes sure that neither the username nor the uid is already in use. It makes a matching group for each user (with gid=uid) - it doesn't check if the gid or group name already exists (left as an exercise for the reader - hint: use getent group). Note: the script below is untested but I've written ...


1

You can use usermod or edit the group file directly # usermod -a G ${group} ${user} # vi /etc/group ... wheel:x:10:root,user1,user2 ... Just remember group changes do not always propagate to active sessions. If you are changing your own user logout and then log back in.


1

Issue the following command after logging in: HISTFILE= This will block any subsequent commands from being logged to the history file.



Only top voted, non community-wiki answers of a minimum length are eligible