Quoting "Simon Ruderich" <si...@ruderich.org>:
It's an invasion of privacy, as I said, for normal users.
In your case, if you're changing to an unprivileged user without a
shell nor password, probably some sort of "locked" account, how is an
attacker going to make use of TIOCSTI to exploit your system?
(Assuming you're not going to run untrusted applications).
Now imagine that that locked user got compromised. Changing to a
compromised user IS and will ALWAYS be bad practice. So, if you don't
know if the user is compromised or not, don't log into that account,
as simple as that. All sorts of bad things can happen.
Just my 2 cents.
On Mon, Oct 03, 2016 at 09:58:23PM +0200,
up201407...@alunos.dcc.fc.up.pt wrote:
Anyways, it is bad admin practice and/or an invasion of privacy to su to an
unprivileged user.
Please explain to me why this is bad admin practice.
Lets assume I have an unprivileged user which is used to execute
a script in an isolated context. Now that script breaks and I
have to debug it. The user has no shell nor password. How do I
run a command as that user? What I did in the past was to run su
-s /bin/sh user and then debug and fix the problem. What is wrong
with that setup?
This has been talked alot in the past, in most of the times even closed as
"WONTFIX".
In that case su should prevent a user from doing it, not causing
a security hole and not documenting that fact.
What I'm saying is, it's OK if you can't come up with something. Better use
'su -c' in any case.
Often a terminal with a shell makes debugging much less painful.
su -c doesn't help there.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
