users
print the user names of users currently logged in to the current host
Synopsis
users
[OPTION]... [FILE]
add an example, a script, a trick and tips
examples
source
Is there a way in Linux to update the user/group properties without having to login again?
I've read before that the newgrp
command does this, but only for the current shell. There doesn't
seem to be a better alternative than to log out and back in
again.
source
Why do some packages require their own user to run?
Because the authors of those programs choose to use separate user
databases rather than using the system password database.
One reason why that is sometimes done is if the program needs to
have access to the plaintext version of the password, perhaps
because it is implementing a network protocol which requires
that, as there is no way to access the plaintext passwords for
system users as they are only held in hashed form.
That is true for example with apache, and by extension for svn
when it is using HTTP basic authentication, as HTTP basic
authentication requires access to the plaintext passwords.
source
How to switch users without entering password
Did you try link text. This is a little dangerous if you
don't know how to handle the shadow password file, however,
probably the simplest way to do what you want.
source
Duplicating Linux-like user account permissions in Windows 7
Left in it's default configuration, running an account with USER
permissions on Windows 7 will have essentially the effect you're
describing, gmunk.
User Access Control (UAC) and the default rights of a USER
account set account permissions more or less exactly as you
describe. No special configuration necessary.
UPDATE:
It depends. As always.
Depending on what you're doing with the computer your security
requirements will change.
-
Is this a home computer that will be the only computer
in the house? Add some antivirus software and you're
pretty much OK.
-
Is this a corporate workstation? If the
corporate network is secured properly, the security of
individual workstations within the network is less important
and is usually turned down a little to enable communication
with the rest of the network.
-
Is this a desktop that will not move and will always be
connected to the same network? Probably somewhere
between the corporate setup and the single-computer home setup.
You'll want to be able to share printers and maybe files and
media between the computers, so you'll want to make sure they
trust each other but don't accept communication from
non-trusted computers as well as more robust antivirus.
-
Is this a laptop that will be traveling?
You'll want really, really strong security. A local firewall
installed on the computer (the Windows firewall is OK, you may
prefer something else though) and good antivirus software.
-
Does the user need to be able to install
stuff? Probably not based on your question.
source
Linux username@server disappears after login as root
Do a few exit
commands. Your su root
started a subshell where you're root, and your su
user
started another. Typing exit
will end
those subshells and bring you back where you started -- one level
deep.
source
Linux groups for standard user
You don't need to have users members of any of them to get a
functioning desktop, however, you may wish to add them to some
for convenience.
The audio
and video
groups allow the
user to make changes to sound and display settings.
The cdrom
group allows the user to eject the cdrom.
The users
group is a ready made group for sharing.
If all users are members of this group, they can create files
with the :users group name, and then add permissions to allow
others to access them.
The sudo
group allows the user to escalate to root
(if sudo is installed) for as single command, or for multiple
commands.
The dialout
group is useful if you are on laptop and
have a modem.
The plugdev
group allows popups for removable
devices, and to manage them.
source
Creating a Linux utility : users/groups/permissions best practice
For clarity, the problem with your code is that unprivileged
users can only seteuid in a few cases based on how the
executable was invoked. So we need another solution.
This is an interesting problem. There are different ways you
could solve it. I don't know if there is an accepted
best-practice solution, but here are some options.
-
Set sticky-group permissions on
/var/cache/utility
.
This approach allows your utility to run under the initiators
permissions. Make sure the user is in the group that owns
/var/cache/utility
, and change the permissions
so that the group assignment is sticky for all contents. You
can accomplish that with the following:
mkdir /var/cache/utility
chown -R :user /var/cache/utility
chmod 2770 /var/cache/utility
usermod -a -G users joe
Now, since joe
is in the users
,
when he runs your utility everything is ok. The group
premission of any modified files in
/var/cache/utility
will remain
users
. The problem is that there is no group to
which all users automatically belong. So this method won't
automatically work for all users. There is also the security
problem. You utility might modify files in
/var/cache/utility
in a well-behaved way, but
this methods opens up the flood-gates to the wild west of
userland.
-
Split your utility into front- and
back-ends.
Dividing the utility into front- and back-ends is
inconvenient, but does force you to formalise the operational
interface. The communication between the parts can take two
common forms:
-
Socket comms, whether unix sockets or TCP
sockets. This requires that your back-end be a
service.
-
Command-line tools. This is considerably simpler
that using sockets, and your back-end does not run
continuously.
The idea is to uid-execute-sticky-bit on your back-end, so
that it automatically runs under the owner's account,
regardless of the current logged-in user. The front-end will
still run under the credentials of the user.
See if you can split your utility so that all manipulation of
the cache is performed by the backend, but other activities
are performed in the front-end. You can set the uid of the
back-end as follows:
chmod u+s /usr/bin/utility-back-end
There is a reasonably good overview of this technique
here. It is still somewhat inconvenient to
partition the software like this, but it is the best solution
I know. The following command will list all the utilities on
your system that already use this method:
find / -xdev \( -perm -4000 \) -type f -print0 | xargs -0 ls -l
Hope that helps.
source
UNIX home folder permissions - no access for other users
You could just change the permissions of your other (sensitive)
subdirs with chmod 700 ~/sensitivedir
.
description
Output who is
currently logged in according to FILE. If FILE is not
specified, use /var/run/utmp. /var/log/wtmp as FILE is
common.
--help
display this help and exit
--version
output version information and
exit
copyright
Copyright © 2012 Free Software Foundation, Inc. License GPLv3+:
GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute
it. There is NO WARRANTY, to the extent permitted by law.
reporting bugs
Report users bugs to bug-coreutils[:at:]gnu[:dot:]org
GNU coreutils home page:
<http://www.gnu.org/software/coreutils/>
General help using GNU software:
<http://www.gnu.org/gethelp/>
Report users translation bugs to
<http://translationproject.org/team/>
see also
The full
documentation for users is maintained as a Texinfo
manual. If the info and users programs are
properly installed at your site, the command
info
coreutils 'users invocation'
should give you
access to the complete manual.
author
Written by
Joseph Arceneaux and David MacKenzie.