Error trying to Empty Trash

And DenverD’s example shows how important it is tat one is aware of the role one has at every moment in time when being on the system. When you, as system manager, thinks that a user must change something, tell the user, even if that is you (it makes communication very fast, but do not make it to fast by not changing roles aka log in as the correct user).

And when you, as system manager, think that the user is not able to handle your request, or you are sure that you want to do this for him as a favour, just use

su - the-user

as root you do not need his password.

I know its wrong but for me within just a few seconds even at worst (assuming my code is correct!) no more than a couple of minutes at the outside its faster and more efficient to login to the GUI as root to create a new virtual host in /etc/apache2/virtualhost.conf by copying an existing block of code and amending it, save it and restart apache, test the virtual host and logout.

Using VI or emacs takes forever and why login twice, login get the job done, log out, job done. It may be months before i need to go anywhere near it again sometimes.

Small editing is done using putty and emacs logged in as root.

If i was using this Linux box as a PC or using it every day to perform administrative / root tasks then yes i would have to change and i would or if this linux box was apart of a much larger IT infrastructure with many users etc.

The only time i have created an insurmountable problem is when i have tried to do something logged in as a user or root at the command prompt either locally or remotely. I have in the past had / created several problems installing the OS and apps. Once complete i rarely have a problem for many months or longer. Because this Linux computer isn’t used as a pc and is used so infrequently remembering how to do things that you did many months even longer ago is very difficult even impossible.

With this server i started with the intension of using it more as a PC, having created / identified so many annoying problems with it and after 3 or 4 re installs i’ve moved back to MS Windows (Win7) computers and this Linux box is just a number of excellent and invaluable network servers.

Linux is the best at this but as a daily PC i can’t cope with it.

Mark

On Tue, 11 Jan 2011 20:22:46 +0000, DenverD wrote:

> DON’T TRY THIS AT HOME: maybe an administrator logs into the GUI as
> root, opens a file manager and nav to Jim’s users directory /home/jim/

That is very different from “just logging in will hork your system up”,
though. That actually defines the exception that I had already made.

> when all is tidy he logs out as root and logs back in as Jim…bingo,
> most likely you cannot log in…i admit, sometimes you can log in,
> sometime the /home/jim/.ICE* file will be owned by root and you can’t
> have that…

Then that would be a bug and should be reported as such, shouldn’t it?
After all, if root is logged in (yes, I agree, bad practice, but
nevertheless it can and does happen) and files that shouldn’t be changed
are changed, that sounds like a bug to me.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Thank you i’ll try kdesu kwrite a little later on. This sounds like a solution that will work for me

There is only one user that can login, me

Virtual host users can login using an ftp client only and nothing else whatsoever. I host a small number of websites for small clubs and groups.

Even my own account is unused, the only time i login as myself is via a putty session to then get root access.

Network Shared locations are owned by me and are UserName and PassWord prtected. When deleting data from these locations as root i’ve never had problems yet logging in afterwards as a user.

So only delete files from these locations logged in as user not root, i can do that if kdesu kwrite works for me.

Mark

kdesu kwrite works for me, excellent thank you.

In thoery i will never have to login to a GUI as root again ever.

Thank you

You are welcome.

Hi
If your only add a virtual host, look at webyast and the http module or webmin.

Hi, i do other things too on rare occasions but thank you though.

i’m going to try and get antivir to work via one of my own scripts.

i’m assuming that to run one of my own scripts as root to use antivir to scan MS Windows data i can use: kdesu ScriptFileName -DirectoryName

Normally i would login using putty then get root access then offer the command scanfiles -DirectoryName. The script “scanfiles” updates antivir then gets antivir to do a virus scan in the location DirectoryName.

I’ll try this tomorrow, antivir will only run as root

Mark

Hi, i do other things too on rare occasions but thank you though.

i’m going to try and get antivir to work via one of my own scripts.

i’m assuming that to run one of my own scripts as root to use antivir to scan MS Windows data i can use: kdesu ScriptFileName -DirectoryName

Normally i would login using putty then get root access then offer the command scanfiles -DirectoryName. The script “scanfiles” updates antivir then gets antivir to do a virus scan in the location DirectoryName.

I’ll try this tomorrow, antivir will only run as root

Mark

akwe-xavante wrote:
> In thoery i will never have to login to a GUI as root again ever.

that is great progress towards a more secure and well administered
linux box…

congrats!


DenverD
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

What if there were no hypothetical questions?

Jim Henderson wrote:
> On Tue, 11 Jan 2011 20:22:46 +0000, DenverD wrote:
> That is very different from “just logging in will hork your system up”,
> though.

who said that? i said many times (you can google it): "you should
never log into KDE/Gnome/XFCE or any other *nix-like graphical user
interface desktop environment as root…

doing so 1) opens you up to several different security problems, 2)
too many too easy ways to damage your system no matter how careful
your actions (example: just browsing in your home directory while
logged into KDE/Gnome/etc as root can lock you out later as yourself
due to permissions damage), 3) and, anyway logging into KDE/etc as
root is never required to do any and all administrative duties…"

and shorter/longer versions of the same…i don’t recall ever saying
that just logging in will bork your system up…

i’ve had it pointed out by several that “just browsing” with a root
powered file manager won’t mess up .ICE*, but…well, why get that
close? when #3 above s true…there is never a need to log into the
gui as root to do any admin duty…(if that were true then every
linux server and embedded system on the planet would have to have X,
right?)

DON’T DO THIS AT HOME: while “just browsing” go ahead and click on any
user file…maybe you get locked out, maybe not…

> Then that would be a bug and should be reported as such, shouldn’t it?

bug? i don’t know, it has been the way it is since ~2002 (at least, i
do NOT remember…it could have been a year or two earlier or
later)… because at that time it was already ‘widely’ known by old
gray haired big iron men from the early days to not do it in any nix
like OS…when i told’em what i did they laughed and told me how to
repair ICE

now, if you wanna log a bug then go ahead and log in as root and
develop the always reproducible steps to bugger up ICE, and report
it…i understand there is more than one way and i don’t wanna look
for them…

for me, it is a lot easier and safer to not log into the gui as
root…and, un-linux-trained windows admins like the person who began
this thread should (inHo) be guided in the same direction–at least
until such time as your bug has cleared once and for all…in all
distros…

by the way, i have heard it said that some folks find danger in
launching, as a user, a gui file manager with root powers and then
using it to move files into/out, or just touch the files of any of the
non-root users…i don’t do that either but find it harder to
convince others to do what i do (use a terminal and cp, mv, rsync,
whatever…)

ymmv.


DenverD
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

What if there were no hypothetical questions?

On Tue, 11 Jan 2011 22:09:53 +0000, DenverD wrote:

> DON’T DO THIS AT HOME: while “just browsing” go ahead and click on any
> user file…maybe you get locked out, maybe not…

And if you do, that’s a bug. Browsing the filesystem should never, ever,
ever, ever, EVER under any circumstances mess with file system
permissions or ownership. If it does, it’s a bug.

I agree (again) that it’s a bad idea to log in as root, but if we’re
explaining to people why, let’s try not to include reasons that are “if
you do, a puppy will die” or something along those lines. Note that I am
not saying that you (DenverD) specifically have ever said this or are
saying this, but we should as a community avoid using FUD to scare people
off doing things that are not good for their systems.

We should use real facts, or that FUD will undermine the effectiveness of
the message.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Here is the problem, you can log on many time as root and no damage done then one time you do something that changes the permissions on a couple of user files .Xauthority and .IceAuthority seem the two that most often get their permissions changed to root. The user tries to log in as himself and fails. Fixing this is no big deal for you and me but the user just moved from MS and knows nothing. So Since it is never required to log into a GUI as root. All can be done form a user logged GUI. I think the best advice is don’t log into a GUI as root.

Now why something in the X stack feels it needs to use the user files I don’t know and I too feel it is a bug but it is a long standing one that has been around for a long time. I’ve seen this basic problem many times on the forms and never have been able to track exactly what the users did as root to create the problem. Most say they just browsed their home directory. But I always felt that there was more to it. But I also never felt the need to try and reproduce it with the scant knowledge of events leading to the problem. And since I never log into a GUI as root I also never see the problem.

gogalthorp wrote:
> Now why something in the X stack feels it needs to use the user files I
> don’t know and I too feel it is a bug but it is a long standing one that
> has been around for a long time. I’ve seen this basic problem many
> times on the forms and never have been able to track exactly what the
> users did as root to create the problem.

your experience is the same as mine…

hopefully, someday everyone with stature/standing/importance in these
and all other Linux fora will somehow become convinced that saying
“it’s a bad idea to log in as root” or “only do it when absolutely
necessary” or “its not a good idea to…” or “you must be very careful
when . . .” should be changed to:

“Do not log into the desktop environment as root.”

but, it is really really difficult (to impossible) to convince folks
that have not locked themselves out of their user account while being
really really careful when it was absolutely necessary to do it,
quickly…

funny, but the very same folks if i said “do not jump off that bridge”
wouldn’t ask “Why?”, or want to dispute it or discuss it to death, again…


DenverD
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

What if there were no hypothetical questions?

akwe-xavante wrote:
> to scan MS Windows data i can use: kdesu ScriptFileName -DirectoryName

that should work, but is the script an X using application–that is,
does it require X, or is it simply a bash script? if the latter, from
a log into KDE as a user, open a terminal and just do:

sudo ScriptFileName -DirectoryName

i’m not familiar with antivir…i think most folks running a linux
server use ClamAV…

and, someone else mentioned it, but you do realize (i guess) that you
can boot the server to runlevel 3 and X won’t be running (and all that
CPU power can go to apache serving pages/content faster) and then you
could log into the boxes command line (as root) and do

ScriptFileName -DirectoryName

or, just put that in a cron job and let the machine do it
everyday…or ClamAV can be set to look at each piece of mail as it
whizzes through…

when you limit yourself to using only the Windows-way of doing things
you are very limited…


DenverD
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

What if there were no hypothetical questions?

On Wed, 12 Jan 2011 07:06:03 +0000, gogalthorp wrote:

> Here is the problem, you can log on many time as root and no damage done
> then one time you do something that changes the permissions on a couple
> of user files .Xauthority and .IceAuthority seem the two that most
> often get their permissions changed to root. The user tries to log in as
> himself and fails. Fixing this is no big deal for you and me but the
> user just moved from MS and knows nothing. So Since it is never required
> to log into a GUI as root. All can be done form a user logged GUI. I
> think the best advice is don’t log into a GUI as root.

The thing is, the same logic could be used to say “don’t use su either to
do things as root” - if you’re not careful as root (regardless of how you
got there), you can hork things up pretty badly.

IOW, I guess what I’m trying to say is this: Overall system admin
privileges need to be treated with respect, regardless of how you got
there. The user needs to be aware that they can hose their system if
they’re not careful.

Now, the X interfaces make it easier, sure - I won’t dispute that. But
just as you can mess up your system logging into KDE as root, you can
also do so at the console or in a terminal session.

The best rule of thumb to use is this: Use the least amount of rights
necessary to get the job done, and be as granular as you can when doing
it.

Most people will balance that with a factor of convenience as well.
Sure, it’s more safe to use sudo vi /etc/fstab followed by sudo
[whatever], but some will find it more convenient to use “su -” to switch
to root and then do the commands so they don’t have to type “sudo” more
than once.

But switching to root inherently means that IF you do a “rm -rf .” and
don’t pay attention to which directory you’re in, you could end up wiping
your entire system. (Note to the uninitiated lurker who might be reading
this: DO NOT DO THIS!). Do that as a user, and you could end up wiping
your data (which is seen, by some, to be much worse than wiping the
system files anyways - since the system can be recovered but without a
backup the data can’t be).

> Now why something in the X stack feels it needs to use the user files I
> don’t know and I too feel it is a bug but it is a long standing one that
> has been around for a long time. I’ve seen this basic problem many
> times on the forms and never have been able to track exactly what the
> users did as root to create the problem. Most say they just browsed
> their home directory. But I always felt that there was more to it. But
> I also never felt the need to try and reproduce it with the scant
> knowledge of events leading to the problem. And since I never log into a
> GUI as root I also never see the problem.

Same here, but it probably is a bug that needs to be addressed. Having a
bug that’s fairly serious like that, even in a use case that we all agree
the typical user shouldn’t run into seems like a bad idea. The
education should come from being told “slamming your hand in the car door
is bad”, but we shouldn’t make it easier for them to do that. Sure,
they’ll remember the lesson, but they also won’t be able to type for a
few months. :wink:

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

On Wed, 12 Jan 2011 09:30:46 +0000, DenverD wrote:

> funny, but the very same folks if i said “do not jump off that bridge”
> wouldn’t ask “Why?”, or want to dispute it or discuss it to death,
> again…

It’s an important issue. As I’ve said before, I agree that it’s a bad
idea (and that one should use the minimal rights necessary to ever
complete a task on a computer, regardless of which OS you’re using),
HOWEVER that doesn’t mean that a bug that makes it MORE dangerous to do
so should be left unaddressed. It should be identified and squashed so
users who are still learning don’t break their fingers in the proverbial
car door because we made it EASIER for them to slam their fingers in the
door.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Jim Henderson wrote:
> The user needs to be aware that they can hose their system if
> they’re not careful.

and there lies the problem with your view of the situation, because
when the user logs into KDE/Gnome/etc as root, they can be careful to
the max, and do nothing out of the ordinary…do nothing they
wouldn’t do as a simple user and yet STILL lock themselves and any
other normal user on the system out of their accounts…

you can’t be careful enough because no where in the documentation, or
common sense, normal practice or knowledge are the traps to avoid
laid out for study and memory…

i don’t know them all…i don’t who knows them all…i believe Carlos
knows of some that i don’t…i suspect several of the devs and folks
involved in writing the following know more, because they did NOT say
anywhere (as you did) while it is not a good idea to, you can log into
the GUI as root but you can hose your system if you are not careful…

http://en.opensuse.org/SDB:Login_as_root

if you want that info added to the wiki, be my guest…someone will be
right behind you to correct it…

> it probably is a bug that needs to be addressed.

and, i invite you to experiment until you learn one or more repeatable
bugs and then file each…

me, i’d rather never log into the GUI DE as root, not even hunting
bugs…

and, be sure and find them all before we start telling folks it is an
ok normal practice to log into the GUI as root, but be careful!


DenverD
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

What if there were no hypothetical questions?

On Wed, 12 Jan 2011 19:37:28 +0000, DenverD wrote:

> and there lies the problem with your view of the situation, because when
> the user logs into KDE/Gnome/etc as root, they can be careful to the
> max, and do nothing out of the ordinary…do nothing they wouldn’t do
> as a simple user and yet STILL lock themselves and any other normal user
> on the system out of their accounts…

Yes, and that’s why I see that as a bug and something that should be
clearly identified and addressed.

No system should create a situation where this can happen. I don’t care
if it’s Linux, Windows, MacOS - no system should, if the user logs into
the system as an administrator, make it so that normal operations
(especially just “looking around”) can cause the system to become
inoperable.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

Like DenverD suggests, ty to reproduce the bug and report it. Like he, I am not going to login in the GUI as root and thus will not be able to reproduce the bug.