Re: su su- sudo dont work

[CL]

Am 27.01.24 um 10:23 schrieb Hans:

I see this exactly as you and are watching this list for may years.

However, I wanted not to be so directly because I want not to blame anyone on
this list.

But since the beginning, I had the suspicion, that someone just wants to make
fun with us.

Aleady from the beginning I checked after the mail adress (please note, I am
German myself) and found some theater group behind the mailadress.

So I personally(!) believe, the group is making fun with us, but even then I
gave him a chance.

And again I personally(!) (and this is my very personal opinion), I think,
nobody is so stupid, that he/she can not do a su or install a package. NOT
after 2 years!!!

For me, I will get no help here for this person, just ignore it. This is my
very personal decision!

Sorry to say it, but for me personally it looks like fake! Like a morone, like
a troll.

And those I can not support, sorry.

Please excuse, I do not want to hurt anyone, just tell, what I think.

Best regards

Hans


I see very similar posts in the German language list from the last two
years but as Tobias Schwibingerr or similar - also signed by a Sophie

When I asked this question some time ago, it seems that the German language
list had concluded that this person might be a troll (or even a psychology
experiment / AI) :(

Like you, I have attempted to engage - but I think none of us will see
any change - I think the German list pays no attention / may have blocked
this user.






Hello,

I agree completely with you.

Follow this list for appr. one year now and this "person" (Michael 
Schwibinger / Sophie / ???) pop up every couple of month.


He/She works always with the same "scam".

1. Came up with a simple sounding cry for help (Computer / OS destroyed 
or something else)
2. React on questions for clarification with stupid and even more 
confusing answers


What I notice that every popup it is a little bit better with the 
answers. They stay stupid and unrelated but the are more wordy.


So I think at the moment it is a troll who works with AI to generate 
some answers. But this is of course my personal opinion.


For a real psychological experiment the design of the experiment is much 
to poor.


I decided for me not care on threads which are based on a message of 
this persons.


The most disappointing thing is that there is no possibility to block 
such "contributors". As I know. Even a block won't really help. They 
might start with a new email in the same way again.



--
---
mit freundlichen Grüßen / Best Regards

**Christian Lorenz**

mailto:cl.debian.mail...@t-online.de
---

Re: su su- sudo dont work

[Christian Lorenz]

Yes,

He/She is back again.

In my opinion no serious request intended by this "person".

Same approach as last time (and the issues before)

* crying for help (destroyed OS)
* no real answers to questions
* repeating the same complain frequently


Some possibilities

1. Shity AI
2. Troll
3. Bored child
4. 
5. ...

I think best thing: ignore it latest after the first fail response to a clear 
quedtion.



--- 
Mit freundlichen Grüßen / Best Regards

**Christian Lorenz**

mailto:cl.debian.mail...@t-online.de
--- 

Am 20. Januar 2024 15:34:16 MEZ schrieb David Wright :
>On Sat 20 Jan 2024 at 09:14:30 (-0500), Greg Wooledge wrote:
>> On Sat, Jan 20, 2024 at 01:26:06PM +, Schwibinger Michael wrote:
>> > Good afternoon.
>> > Root terminal is fine.
>> > What do I do wrong?
>> > What did I destroy?
>> > 
>> > PC does have only one user=admin.
>> > 
>> > Regards Sophie
>> > Is it the rescue mode?
>> 
>> Explain, please.
>> 
>> Your Subject: header says "su su- sudo dont work".  What does this MEAN?
>> 
>> Please show us your attempts to USE each of these commands, and the
>> results that you got.  This means, run the commands in a terminal
>> window, and then PASTE the contents of that terminal window into the
>> body of your next email.  Show us the shell prompt, the command as you
>> typed it, and the full output.
>> 
>> In other words, show us WHAT IS WRONG, or at least what appears wrong.
>> 
>> In addition, please give basic background information -- what version
>> of Debian you are running, what desktop environment if any, how you
>> logged in (*especially* if it isn't just a "standard graphical login
>> for your desktop environment"), and anything else you can think of
>> that might be relevant.
>> 
>> How does "rescue mode" factor into the problem?
>> 
>> When you installed Debian, did you give a root password, or did you
>> leave it blank?
>> 
>> Finally, it would be helpful for you to run the "id" command (with no
>> arguments), in the same terminal session as your failed su or sudo
>> command(s), and include that command and its output in your paste.
>
>Welcome to the world of déjà vu.
>
>  https://lists.debian.org/debian-user/2022/07/msg00601.html
>
>Cheers,
>David.
>

Re: su su- sudo dont work

[Gareth Evans]

> On 23 Jan 2024, at 18:30, Hans  wrote:
> 
> Am Dienstag, 23. Januar 2024, 13:54:25 CET schrieb Schwibinger Michael:
> For gvetting root as normal user, best is use "su -".
> 
> Note: It is not "su-", but "su -", with a space between su and the minus sign.

Also su requires root's password, not the user's, just in case that's worth 
mentioning...

Re: su su- sudo dont work

[Timothy M Butterworth]

On Sun, Jan 21, 2024 at 4:07 PM Schwibinger Michael 
wrote:

> Thank You
> Example
> I say
>
> sudo apt-get install firefox
> Reaction LINUX
> This is not allowed we send a message to the admin.
>

This error message means that your account is not in the sudo group.

Run the command "groups" and look for the group sudo.
groups

Here is the command to add a user account to the sudo group. You will need
to run it as root.
usermod -a -G sudo 


> I do open root terminal
> there its working.
> Regards
> Sophie
>
> --
> *Von:* Greg Wooledge 
> *Gesendet:* Samstag, 20. Januar 2024 14:14
> *An:* debian-user@lists.debian.org 
> *Betreff:* Re: su su- sudo dont work
>
> On Sat, Jan 20, 2024 at 01:26:06PM +, Schwibinger Michael wrote:
> > Good afternoon.
> > Root terminal is fine.
> > What do I do wrong?
> > What did I destroy?
> >
> > PC does have only one user=admin.
> >
> > Regards Sophie
> > Is it the rescue mode?
>
> Explain, please.
>
> Your Subject: header says "su su- sudo dont work".  What does this MEAN?
>
> Please show us your attempts to USE each of these commands, and the
> results that you got.  This means, run the commands in a terminal
> window, and then PASTE the contents of that terminal window into the
> body of your next email.  Show us the shell prompt, the command as you
> typed it, and the full output.
>
> In other words, show us WHAT IS WRONG, or at least what appears wrong.
>
> In addition, please give basic background information -- what version
> of Debian you are running, what desktop environment if any, how you
> logged in (*especially* if it isn't just a "standard graphical login
> for your desktop environment"), and anything else you can think of
> that might be relevant.
>
> How does "rescue mode" factor into the problem?
>
> When you installed Debian, did you give a root password, or did you
> leave it blank?
>
> Finally, it would be helpful for you to run the "id" command (with no
> arguments), in the same terminal session as your failed su or sudo
> command(s), and include that command and its output in your paste.
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: su su- sudo dont work

[Byung-Hee HWANG]

On Sat, 2024-01-20 at 13:26 +, Schwibinger Michael wrote:
> 
> Good afternoon.
> Root terminal is fine.
> What do I do wrong?
> What did I destroy?
> 
> 
> PC does have only one user=admin.
> 
> 
> Regards Sophie
> Is it the rescue mode?

Hellow Sophie,

English is not my native language. Sometimes i use Korean mailing list
for me. Because i am Korean and i feel hard to write/speak English.


I guess English is not your native language. There is a German-only Q
mailing. See  please.


Es gibt ein Q nur auf Deutsch.

Schau hier:



Sincerely, Byung-Hee from South Korea

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: su su- sudo dont work

[Andy Smith]

Hi,

On Sat, Jan 20, 2024 at 01:26:06PM +, Schwibinger Michael wrote:
> Good afternoon.
> Root terminal is fine.
> What do I do wrong?
> What did I destroy?

h-boy, strap yourselves in for another epic Sophie/Michael
thread. A bit like the Gene ones, though tend to be circular across
a much smaller pool of non-information, and far less chance of
bringing up the Korean war. Equally pessimistic as to the chances
of ever reaching a resolution.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: su su- sudo dont work

[David Wright]

On Sat 20 Jan 2024 at 09:14:30 (-0500), Greg Wooledge wrote:
> On Sat, Jan 20, 2024 at 01:26:06PM +, Schwibinger Michael wrote:
> > Good afternoon.
> > Root terminal is fine.
> > What do I do wrong?
> > What did I destroy?
> > 
> > PC does have only one user=admin.
> > 
> > Regards Sophie
> > Is it the rescue mode?
> 
> Explain, please.
> 
> Your Subject: header says "su su- sudo dont work".  What does this MEAN?
> 
> Please show us your attempts to USE each of these commands, and the
> results that you got.  This means, run the commands in a terminal
> window, and then PASTE the contents of that terminal window into the
> body of your next email.  Show us the shell prompt, the command as you
> typed it, and the full output.
> 
> In other words, show us WHAT IS WRONG, or at least what appears wrong.
> 
> In addition, please give basic background information -- what version
> of Debian you are running, what desktop environment if any, how you
> logged in (*especially* if it isn't just a "standard graphical login
> for your desktop environment"), and anything else you can think of
> that might be relevant.
> 
> How does "rescue mode" factor into the problem?
> 
> When you installed Debian, did you give a root password, or did you
> leave it blank?
> 
> Finally, it would be helpful for you to run the "id" command (with no
> arguments), in the same terminal session as your failed su or sudo
> command(s), and include that command and its output in your paste.

Welcome to the world of déjà vu.

  https://lists.debian.org/debian-user/2022/07/msg00601.html

Cheers,
David.

Re: su su- sudo dont work

[Dan Ritter]

Schwibinger Michael wrote: 
> Good afternoon.
> Root terminal is fine.
> What do I do wrong?
> What did I destroy?
> 
> PC does have only one user=admin.
> 
> Regards Sophie
> Is it the rescue mode?

Please tell us:

 exactly what rescue mode you were using

 exactly what the prompt was

 exactly what you typed

 exactly what the response was

 exactly what you want to have happen

Unless you tell us all of these things in one email message, it
will not be a good idea for any of us to try to help you.

Re: su su- sudo dont work

[Hans]

Am Samstag, 20. Januar 2024, 14:26:06 CET schrieb Schwibinger Michael:
There is not "su su-", but there is

su  = change to root, envirenmont of former user without changing of X 
environment (hope, this is corect said)
su -= change to root, environment of user root
su -p   = change to root, environment of former user (usefull when in 
window manager and you want to start graphical applications with root rights)
 
Hope this helps.

Best

Hans
 


> Good afternoon.
> Root terminal is fine.
> What do I do wrong?
> What did I destroy?
> 
> PC does have only one user=admin.
> 
> Regards Sophie
> Is it the rescue mode?

Re: su su- sudo dont work

[Greg Wooledge]

On Sat, Jan 20, 2024 at 01:26:06PM +, Schwibinger Michael wrote:
> Good afternoon.
> Root terminal is fine.
> What do I do wrong?
> What did I destroy?
> 
> PC does have only one user=admin.
> 
> Regards Sophie
> Is it the rescue mode?

Explain, please.

Your Subject: header says "su su- sudo dont work".  What does this MEAN?

Please show us your attempts to USE each of these commands, and the
results that you got.  This means, run the commands in a terminal
window, and then PASTE the contents of that terminal window into the
body of your next email.  Show us the shell prompt, the command as you
typed it, and the full output.

In other words, show us WHAT IS WRONG, or at least what appears wrong.

In addition, please give basic background information -- what version
of Debian you are running, what desktop environment if any, how you
logged in (*especially* if it isn't just a "standard graphical login
for your desktop environment"), and anything else you can think of
that might be relevant.

How does "rescue mode" factor into the problem?

When you installed Debian, did you give a root password, or did you
leave it blank?

Finally, it would be helpful for you to run the "id" command (with no
arguments), in the same terminal session as your failed su or sudo
command(s), and include that command and its output in your paste.

Re: su

[Max Nikulin]

On 14/09/2023 22:26, Vincent Lefevre wrote:


I noticed the issue just before the upgrade to bookworm (I wanted
to do that for the upgrade). But I can't reproduce it in bookworm.
So this may have been an old bug that has been fixed.


I do not follow the topic, so I can not attribute changes to particular 
releases, but certainly I see progress: new features in terminal 
applications, changes in terminal definitions, adding new ones like tmux 
flavors.



IIRC, this was text positioning issues, perhaps when recalling
commands from the history.


It may be related to a readline library. E.g. bash does not rely on

xterm*VT100.reverseWrap: true


BTW, I don't think that the preservation of $TERM is sufficient.
Preserving $TERMINFO (when set) is important too.


I do not use TERMINFO, however if you need to preserve it than you may use

su --whitelist-environment=TERMINFO -

My use case is lxc-attach and DISPLAY.

Re: su

[Vincent Lefevre]

On 2023-09-14 21:25:56 +0700, Max Nikulin wrote:
> On 14/09/2023 17:30, Vincent Lefevre wrote:
> > Yes, XDG_RUNTIME_DIR is problematic, but as "su -" doesn't work in
> > GNU Screen (it yields major display issues), I presume that some
> > environment variables (terminal related?) are still useful.
> 
> I just have tried it. "su -" preserves TERM=screen.xterm-256color. Behavior
> is different from pure xterm-256color, but I have no guess what you may
> consider as major display issues. E.g. vim is even able to determine if
> background is dark or light and to adjust color scheme accordingly.

I noticed the issue just before the upgrade to bookworm (I wanted
to do that for the upgrade). But I can't reproduce it in bookworm.
So this may have been an old bug that has been fixed.

IIRC, this was text positioning issues, perhaps when recalling
commands from the history.

BTW, I don't think that the preservation of $TERM is sufficient.
Preserving $TERMINFO (when set) is important too.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: su

[Max Nikulin]

On 14/09/2023 17:30, Vincent Lefevre wrote:

Yes, XDG_RUNTIME_DIR is problematic, but as "su -" doesn't work in
GNU Screen (it yields major display issues), I presume that some
environment variables (terminal related?) are still useful.


I just have tried it. "su -" preserves TERM=screen.xterm-256color. 
Behavior is different from pure xterm-256color, but I have no guess what 
you may consider as major display issues. E.g. vim is even able to 
determine if background is dark or light and to adjust color scheme 
accordingly.

Re: su

[Vincent Lefevre]

On 2023-09-06 14:36:48 +0700, Max Nikulin wrote:
> On 06/09/2023 10:41, Greg Wooledge wrote:
> > 
> > Just put "ALWAYS_SET_PATH yes" into /etc/default/su and the problem
> > is FIXED.  "su" will work properly again!
> 
> Greg, you provided a valid example when "su -" is undesirable, however in
> general "su -" is safer than just "su" since it resets some user specific
> environment variables like XDG_RUNTIME_DIR=/run/user/1000 that may cause
> creation of files that the original user can not overwrite them. So "su -"
> should have less unexpected effects.

Yes, XDG_RUNTIME_DIR is problematic, but as "su -" doesn't work in
GNU Screen (it yields major display issues), I presume that some
environment variables (terminal related?) are still useful.

FYI, I had written a su wrapper that unsets XDG_RUNTIME_DIR first.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: su

[Michel Verdier]

On 2023-09-05, Greg Wooledge wrote:

> How *incredibly* Red Hat.  Really, it just sickens me that this is the
> answer accepted by so many people.

It's not Red Hat, it's man page and own practice, even before Red Hat
exists :)

> To perform that installation, you run "su", which gives you a root shell,
> and then you do something like "make install".

I either do all as root, after "su -", or use sudo for a single command.

Re: su

[Max Nikulin]

On 06/09/2023 10:41, Greg Wooledge wrote:


Just put "ALWAYS_SET_PATH yes" into /etc/default/su and the problem
is FIXED.  "su" will work properly again!


Greg, you provided a valid example when "su -" is undesirable, however 
in general "su -" is safer than just "su" since it resets some user 
specific environment variables like XDG_RUNTIME_DIR=/run/user/1000 that 
may cause creation of files that the original user can not overwrite 
them. So "su -" should have less unexpected effects.



Unfortunately, Debian DOESN'T CREATE THIS FILE BY DEFAULT.  People are
scared to create it themselves, because people have been "trained"
by years of Linux distribution handholding that if a program has
a configuration file, that file will *exist*, and will have helpful
comments in it, and they only have to find the file and edit it.
The idea of *creating* a configuration file that's missing is terrifying
for some people.


I find it more convenient when a configuration file may be created in 
addition to ones provided by the package. It makes changes more visible. 
It may be advantage or disadvantage if during package upgrade default 
configs are replaced without a query related to changed directives.


This particular settings is described in su(1) so can be discovered by 
users with reasonable amount of efforts. Certainly a configuration 
example may still be preferable for users.

Re: su

[Charlie]

On Tue, 5 Sep 2023 23:41:45 -0400
Greg Wooledge  wrote:

> To perform that installation, you run "su", which gives you a root
> shell, and then you do something like "make install".
> 
> But the Red Hat answer says you should use "su -" instead, to become
> root. What happens now?  You've created a login shell.  Now you're no
> longer in the directory where your source code was extracted and
> compiled. You're in root's $HOME directory.  So "make install" fails.
> 
> You could use a "cd" command to get to the source code.  But "cd -"
> won't work, because the previous working directory is not known to
> the root login shell.  The root login shell has intentionally
> discarded everything from your previous shell, including the old
> working directory's name. So you can't "cd -", but instead, you have
> to re-type the entire path to the source code directory.  Or copy and
> paste it out of your shell prompt, if that's still visible on the
> screen, and if it happens to contain the entire path.
> 
> Wouldn't it be *nicer* if su simply WORKED?!
> 
> You can make su work by creating a ONE-LINE CONFIGURATION FILE.

Thank you Greg
-- 
**  **  **  **  **  **  **  **  **  **
Registered Linux User:- 329524
***

There is no exercise better for the heart than reaching down
and lifting people up.-- John Holmes

***
Debian GNU/Linux - just the best way to create magic
___

Re: su

[Greg Wooledge]

On Wed, Sep 06, 2023 at 05:09:29AM +0200, Michel Verdier wrote:
> On 2023-09-05, Greg Wooledge wrote:
> 
> > You used "su" to become root, I believe.  Unfortunately, beginning
> > with Debian 9, "su" with no arguments and no configuration doesn't
> > behave the way it used to behave.  Specifically, it no longer sets the
> > PATH variable properly.  And so you get the above results.
> >
> > See  for the options
> > available to you.  If you wish to continue using su, I strongly recommend
> > creating a /etc/default/su file.
> 
> I have no /etc/default/su and never need one. According to the man page
> su also reads /etc/login.defs. To get root env she only needs to use:
> "su -"

How *incredibly* Red Hat.  Really, it just sickens me that this is the
answer accepted by so many people.

Do you want a *specific* reason why this answer is crap?  OK, here's my
reason.

Let's say you've downloaded a program in source code form from the Internet.
You unpack it, and read the installation instructions.  Then you end up
running some combination of "./configure" and "make", or maybe "cmake",
or something like that.  Then, when all that fun stuff is done, it's time
to install your new program into the system directories so it can be used.

To perform that installation, you run "su", which gives you a root shell,
and then you do something like "make install".

But the Red Hat answer says you should use "su -" instead, to become root.
What happens now?  You've created a login shell.  Now you're no longer
in the directory where your source code was extracted and compiled.
You're in root's $HOME directory.  So "make install" fails.

You could use a "cd" command to get to the source code.  But "cd -" won't
work, because the previous working directory is not known to the root
login shell.  The root login shell has intentionally discarded everything
from your previous shell, including the old working directory's name.
So you can't "cd -", but instead, you have to re-type the entire path to
the source code directory.  Or copy and paste it out of your shell prompt,
if that's still visible on the screen, and if it happens to contain the
entire path.

Wouldn't it be *nicer* if su simply WORKED?!

You can make su work by creating a ONE-LINE CONFIGURATION FILE.

Just put "ALWAYS_SET_PATH yes" into /etc/default/su and the problem
is FIXED.  "su" will work properly again!

> su also reads /etc/login.defs

Yes, it does.  And when the buster problem was first noted, some people
discovered that putting ALWAYS_SET_PATH yes into /etc/login.defs would
fix su.  This was actually published on the Debian wiki as well, as it
was the first known fix for the broken su.

Unfortunately, this fix has an undesired side effect.  It causes console
logins to print an error message, because the ALWAYS_SET_PATH line in
/etc/login.defs is not known to login(1), but only to su(1).

This error doesn't actually *hurt* anything, but it's really annoying.
And scary, for people who don't know where it's coming from.

Putting the configuration in /etc/default/su is a *better* solution,
because it works, and doesn't cause logins to print a confusing error
message.

Unfortunately, Debian DOESN'T CREATE THIS FILE BY DEFAULT.  People are
scared to create it themselves, because people have been "trained"
by years of Linux distribution handholding that if a program has
a configuration file, that file will *exist*, and will have helpful
comments in it, and they only have to find the file and edit it.
The idea of *creating* a configuration file that's missing is terrifying
for some people.

That's why I put the extra advice "(create it)" on the wiki.  I know
it won't be strong enough advice to overcome everyone's fears, but I do
hope it's enough to encourage people who are on the fence to be brave.
To reassure them that yes, we know Debian screwed up, and yes, we know
the file *should* be there, and it's not, but that's OK.  You can make
it yourself.

Re: Su correo ha sido recibido por soporte...@cantv.net

[walter]

falta poner el numero de la tarjeta y codigo de seguridad

Aura Hernandez:

Buenas tardes debido a
Inconveniente presentado , necesito reducir al
Mínimo  el plan q mantengo con uds de internet, ya se hace difícil pagar dicha 
obligación... mi tel es +58 2869235678 a nombre de aura hernandez, cédula de 
identidad nro 5342754... cualquiera contesta al respecto favor comunicarse 
conmigo mediante el correo linefa...@hotmail.com

Enviado desde mi iPhone


--

Re: Su correo ha sido recibido por soporte...@cantv.net

[Aura Hernandez]

Buenas tardes debido a
Inconveniente presentado , necesito reducir al
Mínimo  el plan q mantengo con uds de internet, ya se hace difícil pagar dicha 
obligación... mi tel es +58 2869235678 a nombre de aura hernandez, cédula de 
identidad nro 5342754... cualquiera contesta al respecto favor comunicarse 
conmigo mediante el correo linefa...@hotmail.com 

Enviado desde mi iPhone

Re: su - kees en DISPLAY voor kees

[grappig]

On Sun, Mar 21, 2021 at 02:09:19PM +0100, Richard Lucassen wrote:
> On Sun, 21 Mar 2021 10:45:55 +0100 Geert Stappers wrote:
> > On Sun, Mar 21, 2021, Richard Lucassen wrote:
> > > sudo -u kees XAUTHORITY=/home/kees/.Xauthority /path/to/executable
> > 
> > Daarmee aan de slag gegaan en na wat expirimenten:
> > 
> > 
> >   sudo -u kees   xterm &
> > 
> > 
> > En in die Xterm heb ik de gewenste "su - kees" en DISPLAY gevuld.
> 
> Dat hoeft niet:
> 
> sudo -u kees XAUTHORITY=/home/kees/.Xauthority /usr/bin/xterm
> 
> Die is dan al van user kees, je hoeft als het goed is dan niets meer te
> doen in die xterm aan su en zo


Ja

Re: su - kees en DISPLAY voor kees

[Richard Lucassen]

On Sun, 21 Mar 2021 10:45:55 +0100
Geert Stappers  wrote:

> > sudo -u kees XAUTHORITY=/home/kees/.Xauthority /path/to/executable
> 
> Daarmee aan de slag gegaan en na wat expirimenten:
> 
> 
>   sudo -u kees   xterm &
> 
> 
> En in die Xterm heb ik de gewenste "su - kees" en DISPLAY gevuld.

Dat hoeft niet:

sudo -u kees XAUTHORITY=/home/kees/.Xauthority /usr/bin/xterm

Die is dan al van user kees, je hoeft als het goed is dan niets meer te
doen in die xterm aan su en zo

-- 
richard lucassen
http://contact.xaq.nl/

Re: su - kees en DISPLAY voor kees

[Geert Stappers]

On Sun, Mar 21, 2021 at 09:44:45AM +0100, Richard Lucassen wrote:
> xhost wordt om security redenen wel afgeraden.

`xhost +` wordt om security redenen wel afgeraden.
Vandaar de subtielere  `xhost +si:local:kees`
Om een of andere reden gaat dat nu niet meer,
een `xhost +local` wel. Niet heel subtiel.

> Je kunt daarentegen ook de xauth-cookie gebruiken:
> 
> COOKIE=$(xauth list ${DISPLAY} | egrep -wo '[0-9a-f]{32,32}')
> sudo -u kees xauth -f /home/kees/.Xauthority add ${DISPLAY} . ${COOKIE}
> 
> sudo -u kees XAUTHORITY=/home/kees/.Xauthority /path/to/executable

Daarmee aan de slag gegaan en na wat expirimenten:


  sudo -u kees   xterm &


En in die Xterm heb ik de gewenste "su - kees" en DISPLAY gevuld.
Dank.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: su - kees en DISPLAY voor kees

[Richard Lucassen]

On Sat, 20 Mar 2021 21:42:28 +0100
Geert Stappers  wrote:

>   xhost +si:local:kees
>   echo $DISPLAY

xhost wordt om security redenen wel afgeraden. Je kunt daarentegen ook
de xauth-cookie gebruiken:

COOKIE=$(xauth list ${DISPLAY} | egrep -wo '[0-9a-f]{32,32}')
sudo -u kees xauth -f /home/kees/.Xauthority add ${DISPLAY} . ${COOKIE}

sudo -u kees XAUTHORITY=/home/kees/.Xauthority /path/to/executable

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: su - kees en DISPLAY voor kees

[Geert Stappers]

On Sat, Mar 20, 2021 at 09:42:28PM +0100, Geert Stappers wrote:
> On Sat, Mar 20, 2021 at 09:22:24PM +0100, Geert Stappers wrote:
> > Hoi,
> > 
> > Computer met XCFE  daar kan ik `su - kees` doen.
> > Als user kees mag ik geen grafische opstarten
> > want DISPLAY staat niet goed.
> > 
> > Hoe dat wel goed te zetten?
> > 
> 
> Vooraf aan de "switch user"
> 
>   xhost +si:local:kees

Om toestemming te geven voor iets op grafisch scherm te zetten.


>   echo $DISPLAY

Om waarde op te vragen, was  :0.0
 
> Wissel van gebruiker
> 
>   su - kees
 
Er wordt om wachtwoord van kees gevraagd

 
> En als `kees`
> 
>   export DISPLAY=0.0

De eerder opgevraagde waarde opgeven


>   xterm

Grafische applicatie opstarten,
dat is waar het om ging.



Groeten
Geert Stappers

P.S.

Tips hoe het anders kan zijn welkom.
-- 
Silence is hard to parse

Re: su - kees en DISPLAY voor kees

[Geert Stappers]

On Sat, Mar 20, 2021 at 09:22:24PM +0100, Geert Stappers wrote:
> Hoi,
> 
> Computer met XCFE  daar kan ik `su - kees` doen.
> Als user kees mag ik geen grafische opstarten
> want DISPLAY staat niet goed.
> 
> Hoe dat wel goed te zetten?
> 

Vooraf aan de "switch user"

  xhost +si:local:kees
  echo $DISPLAY

Wissel van gebruiker

  su - kees


En als `kees`

  export DISPLAY=0.0
  xterm



Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: su does not work anymore

[Gene Heskett]

On Saturday 02 May 2020 07:19:13 The Wanderer wrote:

> On 2020-05-02 at 06:57, Sven Joachim wrote:
> > On 2020-05-02 10:57 +0200, Rainer Dorsch wrote:
> >> Am Samstag, 2. Mai 2020, 06:32:02 CEST schrieb Andrei POPESCU:
> >>> Ugh. For such situations one should either have good backups or
> >>> a reasonably fast and automated method of reinstalling the
> >>> system.
> >>>
> >>> See also http://taobackup.com
> >>
> >> Thanks for sharing the nice link, Andrei. Unfortunately, I took the
> >> novice approach on step 1 for the system files. I do not see any
> >> issues on the system anymore tough. To be on the saver side, I also
> >> did an "apt-get reinstall" of the relevant packages. I hope the
> >> next "apt-get dist-upgrade" will eliminate any so far hidden
> >> issues.
> >
> > There will likely be a few problems left.  Reinstalling packages
> > fixes the owner and permissions of most ordinary files, but
> > directories are left alone, and some programs (especially daemons)
> > might find themselves unable to write where they are supposed to.
>
> I had to fix my primary system from a more severe version of a similar
> problem, a year or so ago; long story short, when I built the system I
> put /var on a separate RAID array from the rest of the general install
> (because, like /home, it's documented as needing potentially lots of
> space so it didn't seem suited for the smaller-capacity SSD array),
> and when that array died and the data-recovery service gave me my
> files back they had passed the whole thing through a tool that assumes
> and applies a generic Windows-filesystem permission set and mangles
> the filenames into a form that uses only NTFS-legal characters.
>
> It took me three-to-six months of painful, detailed effort, with
> painstaking back-and-forth comparisons against a known-good system and
> lots of manual scripting to redownload the /var/cache/apt/archives/
> contents for verification, to be sure I had everything back together
> to a sufficient degree. Even then, I'm still not sure things are 100%;
> just yesterday, I found a trio of rarely-accessed files (under /home,
> and not config files, fortunately) whose names still had underscores
> in place of colons.
>
> Manual recovery like this *can* be done, but I do not recommend
> embarking upon it without very strong reason. (In my case, I needed to
> fix the filenames and permissions of my entire /home partition anyway,
> and that includes irreplaceable data measuring in terabytes and dating
> in some cases as far back as the '90s. Proper external backup is now
> very much on my radar.)

That leaves amanda, standing alone away from the crowd.  I've used it 
here for over 20 years now as a shorter term solution to getting 
anything back, provided I discover its missing in under 56 or so days.  
I don't use tapes but virtual tapes on a big HD, as real tapes aren't 
near as dependable.  60 of them on a 2T drive ATM.

Drives that aren't shut down don't fail, I have some with nearly 200,000 
spinning hours on them and as good as the day they were first spun up 
decades ago. The Amanda backup scheduler also does not do fulls on 
Friday, but juggles incrementles in an attempt to use about the same 
amount of media for each run. You setup the days of a runcycle and 
amanda juggles the backup levels around while absolutely doing a full on 
every entry in the disklist at least once per runcycle days. It keeps a 
database so it knows what is has and what vtape its in. But with vtapes, 
its not the time consuming sequential tape read to find what it needs as 
the vtape access is random & hundreds of times faster.

I could lose this main drive yet this morning, get in the pickup and run 
up to Staples and get a new drive, bring it back and install linuxcnc 
from the dvd, get that database from last nights backup with tar, 
install amanda, and by 5pm, have this machine back in the exact state it 
was in at this mornings 2AM backup.  Whats not to like?  Have cron run 
it in the wee hours every night and sleep well, knowing you have 
disaster recovery at hand right from your own keyboard.  I'm doing 5 
machines with it. The New York State Dept of Health is doing at least 40 
machines with it.  Cern uses it.  The list goes on.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: su does not work anymore

[The Wanderer]

On 2020-05-02 at 08:32, Carl Fink wrote:

> On 5/2/20 7:19 AM, The Wanderer wrote:
> 
>> Manual recovery like this *can* be done, but I do not recommend 
>> embarking upon it without very strong reason. (In my case, I needed
>> to fix the filenames and permissions of my entire /home partition
>> anyway, and that includes irreplaceable data measuring in terabytes
>> and dating in some cases as far back as the '90s. Proper external
>> backup is now very much on my radar.)
> 
> Why not just reinstall the OS and copy the /home/username files into
> the new /home partition? Reinstalling Debian is extremely easy.

For one thing, I have a fair few packages not necessarily installed
along with the OS, as well as some programs manually compiled and
installed et cetera; digging them all up and getting them back in place
would be a pain in its own right.

For another, I don't have the experience with reinstalling and not
losing data that way in order to trust the result. I've historically
always installed to new drives, and copied the data across from the old
ones. In this case, I didn't have a system to put either the old or the
new drives in with enough ports to hook all the drives up at once, and I
didn't want to risk installing over top and losing the undamaged
remnants of my system.

For a third, I'd have had to fix the /home permissions and filenames
regardless, because /home was on the same array as /var and had gone
through the same ownership-and-permissions metadata-lossy
filename-mangling recovery process.

What I ended up doing might be argued not to have been the most
objectively optimal option in hindsight, but it was what occurred to me
as making sense at the time, and it did end up working - and thereby
proving that (as I said) this type of recovery *can* be done, however
much I don't recommend embarking upon it.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: su does not work anymore

[Carl Fink]

On 5/2/20 7:19 AM, The Wanderer wrote:

Manual recovery like this *can* be done, but I do not recommend
embarking upon it without very strong reason. (In my case, I needed to
fix the filenames and permissions of my entire /home partition anyway,
and that includes irreplaceable data measuring in terabytes and dating
in some cases as far back as the '90s. Proper external backup is now
very much on my radar.)


Why not just reinstall the OS and copy the /home/username files into the
new /home partition? Reinstalling Debian is extremely easy.

--
Carl Fink   nitpick...@nitpicking.com

Read my blog at blog.nitpicking.com.  Reviews!  Observations!

Re: su does not work anymore

[The Wanderer]

On 2020-05-02 at 06:57, Sven Joachim wrote:

> On 2020-05-02 10:57 +0200, Rainer Dorsch wrote:
> 
>> Am Samstag, 2. Mai 2020, 06:32:02 CEST schrieb Andrei POPESCU:

>>> Ugh. For such situations one should either have good backups or
>>> a reasonably fast and automated method of reinstalling the
>>> system.
>>> 
>>> See also http://taobackup.com
>> 
>> Thanks for sharing the nice link, Andrei. Unfortunately, I took the
>> novice approach on step 1 for the system files. I do not see any
>> issues on the system anymore tough. To be on the saver side, I also
>> did an "apt-get reinstall" of the relevant packages. I hope the
>> next "apt-get dist-upgrade" will eliminate any so far hidden
>> issues.
> 
> There will likely be a few problems left.  Reinstalling packages
> fixes the owner and permissions of most ordinary files, but
> directories are left alone, and some programs (especially daemons)
> might find themselves unable to write where they are supposed to.

I had to fix my primary system from a more severe version of a similar
problem, a year or so ago; long story short, when I built the system I
put /var on a separate RAID array from the rest of the general install
(because, like /home, it's documented as needing potentially lots of
space so it didn't seem suited for the smaller-capacity SSD array), and
when that array died and the data-recovery service gave me my files back
they had passed the whole thing through a tool that assumes and applies
a generic Windows-filesystem permission set and mangles the filenames
into a form that uses only NTFS-legal characters.

It took me three-to-six months of painful, detailed effort, with
painstaking back-and-forth comparisons against a known-good system and
lots of manual scripting to redownload the /var/cache/apt/archives/
contents for verification, to be sure I had everything back together to
a sufficient degree. Even then, I'm still not sure things are 100%; just
yesterday, I found a trio of rarely-accessed files (under /home, and not
config files, fortunately) whose names still had underscores in place of
colons.

Manual recovery like this *can* be done, but I do not recommend
embarking upon it without very strong reason. (In my case, I needed to
fix the filenames and permissions of my entire /home partition anyway,
and that includes irreplaceable data measuring in terabytes and dating
in some cases as far back as the '90s. Proper external backup is now
very much on my radar.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: su does not work anymore

[Sven Joachim]

On 2020-05-02 10:57 +0200, Rainer Dorsch wrote:

> Am Samstag, 2. Mai 2020, 06:32:02 CEST schrieb Andrei POPESCU:
>> On Vi, 01 mai 20, 22:32:58, Rainer Dorsch wrote:
>> > Hello,
>> >
>> > I had an accidential / in a
>> >
>> > # chown -R install-user /xyz/dfak /
>> >
>> > command. Changing the ownership / recursively is certainly not a good
>> > idea.
>>
>> Ugh. For such situations one should either have good backups or a
>> reasonably fast and automated method of reinstalling the system.
>>
>> See also http://taobackup.com
>>
>
> Thanks for sharing the nice link, Andrei. Unfortunately, I took the novice
> approach on step 1 for the system files. I do not see any issues on the system
> anymore tough. To be on the saver side, I also did an "apt-get reinstall" of
> the relevant packages. I hope the next "apt-get dist-upgrade" will eliminate
> any so far hidden issues.

There will likely be a few problems left.  Reinstalling packages fixes
the owner and permissions of most ordinary files, but directories are
left alone, and some programs (especially daemons) might find themselves
unable to write where they are supposed to.

Cheers,
   Sven

Re: su does not work anymore

[Rainer Dorsch]

Am Samstag, 2. Mai 2020, 06:32:02 CEST schrieb Andrei POPESCU:
> On Vi, 01 mai 20, 22:32:58, Rainer Dorsch wrote:
> > Hello,
> > 
> > I had an accidential / in a
> > 
> > # chown -R install-user /xyz/dfak /
> > 
> > command. Changing the ownership / recursively is certainly not a good
> > idea.
> 
> Ugh. For such situations one should either have good backups or a
> reasonably fast and automated method of reinstalling the system.
> 
> See also http://taobackup.com
> 

Thanks for sharing the nice link, Andrei. Unfortunately, I took the novice 
approach on step 1 for the system files. I do not see any issues on the system 
anymore tough. To be on the saver side, I also did an "apt-get reinstall" of 
the relevant packages. I hope the next "apt-get dist-upgrade" will eliminate 
any so far hidden issues.

Thanks
Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Re: su does not work anymore

[Andrei POPESCU]

On Vi, 01 mai 20, 22:32:58, Rainer Dorsch wrote:
> Hello,
> 
> I had an accidential / in a 
> 
> # chown -R install-user /xyz/dfak /
> 
> command. Changing the ownership / recursively is certainly not a good idea.

Ugh. For such situations one should either have good backups or a 
reasonably fast and automated method of reinstalling the system.

See also http://taobackup.com

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: su won't work from a debian live USB install

[Phil Wyett]

On Sun, 2017-06-25 at 19:20 -0400, daniel theobald wrote:
> I installed the Debian 9 from a Debian live amd64 image I downloaded
> today.  Everything works great, but I can't su to apt-get anything
> new.
> 
> theo@debian:~$ su
> Password: 
> su: Authentication failure
> 
> I have reinstalled twice, being super careful to get the password
> right, etc.  But it simply doesn't seem to work on this version. 
> Anyone else seeing this problem?
> 
> Thanks,
> Daniel
> 

Hi,

I have seen this issue too.

I have not had time to look into this issue, but believe it maybe
related to a known issue No. 3 on:

https://cdimage.debian.org/debian-cd/9.0.1-live/amd64/iso-hybrid/

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864955

After the live 9.0.0 ISO failed early in install and now the 'su'
issue. This raises questions about the testing and QA of of the live
ISO images, both pre release and at release time that need to be
discussed and addressed in-order to avoid them in the future.

Regards

Phil

-- 
Playing the game for the games sake.

Web: https://kathenas.org

Twitter: kathenasorg

Instagram: kathenasorg

signature.asc
Description: This is a digitally signed message part

Re: su won't work from a debian live USB install

[Jim Ohlstein]

Hello,

On 06/25/2017 07:20 PM, daniel theobald wrote:
I installed the Debian 9 from a Debian live amd64 image I downloaded 
today.  Everything works great, but I can't su to apt-get anything new.


theo@debian:~$ su
Password:
su: Authentication failure

I have reinstalled twice, being super careful to get the password right, 
etc.  But it simply doesn't seem to work on this version.  Anyone else 
seeing this problem?


Assuming sudo is working properly, try resetting the root password:

$ sudo passwd root

--
Jim Ohlstein
Profesional Mailman Hosting
https://mailman-hosting.com

Re: "su is really a broken concept"

[T.J. Duchene]

You're probably right, Jonathan.  "Su" is so common that it easy to make
that error. After looking at the current POSIX list, I did not find it.
Thank you for pointing that out.

Be well!
T.J.

On Wed, Sep 2, 2015 at 10:55 PM, Jonathan de Boyne Pollard <
j.deboynepollard-newsgro...@ntlworld.com> wrote:

> T.J. Duchene:
>
>> If someone can do it better, and still keep it compatible with POSIX,
>> more power to them.
>>
>
> This is not the first place where someone has randomly thrown POSIX into
> the discussion.  "su" is outwith the scope of the POSIX standard.  It's in
> the SVID, but to my knowledge "su" never made into POSIX.  The SUS mentions
> it in passing under setuid() as a non-conformant application.
>
>

Re: "su is really a broken concept"

[Jonathan de Boyne Pollard]

T.J. Duchene:
If someone can do it better, and still keep it compatible with POSIX, 
more power to them. 


This is not the first place where someone has randomly thrown POSIX into 
the discussion.  "su" is outwith the scope of the POSIX standard.  It's 
in the SVID, but to my knowledge "su" never made into POSIX.  The SUS 
mentions it in passing under setuid() as a non-conformant application.

Re: "su is really a broken concept"

[Jonathan de Boyne Pollard]

Lennart Poettering 
(https://github.com/systemd/systemd/issues/825#issuecomment-127917622):



Long story short:  su is really a broken concept.



Christian Seiler:


So it's not like su is suddenly broken - it's just that some specific 
new use cases don't work properly with it.




A fair number of people got their backs up for the very reason that su 
was described as "broken".  One could, of course ask whether in fact it 
is the XDG Base Directory Specification 
(http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) 
that is the broken concept, for incorporating the notion of the only way 
that one reaches the point of running as any given user account being 
login.  ("the user being logged in ... the user first logs in ... the 
user fully logs out ... the user logs in more than once ... first login 
... last logout ... a full logout/login cycle")  Design a mechanism that 
at its foundation and throughout takes no account of adding other user 
account privileges into a login session with su, or indeed that 
processes wanting to create "runtime" files might be set-UID, and of 
course it will conflict.

Re: "su is really a broken concept"

[T.J. Duchene]

On Tue, 2015-09-01 at 01:25 +0100, Jonathan de Boyne Pollard wrote:
> Lennart Poettering 
> (https://github.com/systemd/systemd/issues/825#issuecomment-127917622):
> 
> > Long story short:  su is really a broken concept.
> >
> 
> Christian Seiler:
> >
> > So it's not like su is suddenly broken - it's just that some specific 
> > new use cases don't work properly with it.
> >
I don't think so.  It is what it is.  If someone can do it better, and
still keep it compatible with POSIX, more power to them.  Just let the
rest of us chose which we want. 

That is the open way.

T.J.

Re: su chmod -755 /usr

[Julian Brooks]

Cheers Bob :)

Uuummm  - work files yes, system configs/settings not really.

Any top tips, like where are the permission file/s?

On 12 June 2015 at 22:07, Bob Proulx b...@proulx.com wrote:

 Julian Brooks wrote:
  All seems well, valuable lesson(s) learnt.
  Seriously thought it was terminal, appreciate the wisdom people.

 Glad to hear you solved your problem.  In the future with a similar
 problem you would be able to restore your current system permissions
 from your backup.  Not the entire backup files.  But by using the
 permissions stored on the backup files you could reset the permissions
 on the live files.

 You do have a backup plan, right?  :-)

 Bob

Re: su chmod -755 /usr

[Bob Proulx]

Julian Brooks wrote:
 All seems well, valuable lesson(s) learnt.
 Seriously thought it was terminal, appreciate the wisdom people.

Glad to hear you solved your problem.  In the future with a similar
problem you would be able to restore your current system permissions
from your backup.  Not the entire backup files.  But by using the
permissions stored on the backup files you could reset the permissions
on the live files.

You do have a backup plan, right?  :-)

Bob


signature.asc
Description: Digital signature

Re: su chmod -755 /usr

[Bob Proulx]

Julian Brooks wrote:
 Cheers Bob :)
 
 Uuummm  - work files yes, system configs/settings not really.
 
 Any top tips, like where are the permission file/s?

I think you are asking what backup software would be recommended?
There are many different ones.  Let me point to a reference.

  https://wiki.debian.org/BackupAndRecovery

Personally I always used to use rsync scripts for years.  These days I
am enjoying using BackupPC.  But isn't to say that amanda or bacula or
any of the others are not good too.  They are all the same and all
different.

But you ask about permission files.  I think perhaps I wasn't clear
enough.  For example I could run 'find' down the backup tree and print
the file modes of the files there.

  cd /path/to/backup
  find . -type l -prune -o -printf chmod %m %p\n

There are no whitespace in most files in /usr and therefore the above
would print out a series of commands such as:

  chmod 755 .
  chmod 755 ./bin
  chmod 755 ./bin/vnc4server
  chmod 755 ./bin/xkbevd
  chmod 755 ./bin/pavucontrol
  chmod 755 ./bin/sg_dd
  chmod 755 ./bin/glxgears
  chmod 755 ./bin/sensors-conf-convert
  chmod 755 ./bin/etags.emacs24
  chmod 755 ./bin/qemu-armeb
  ...
  chmod 4755 ./bin/sudo
  ...
  chmod 2755 ./games/hack

Could then inspect the output for anything strange such as whitespace
in filenames.  Then run it as a script, perhaps after editing it.

Bob


signature.asc
Description: Digital signature

Re: su chmod -755 /usr

[Julian Brooks]

Many thanks for the replies.

(I did say I'm sketchy here)

I was attempting to alter permissions on a folder.
I then read that all folders leding up to it must also have permission
altered.

So I then mistakenly actually ran
'sudo chmod -755 /usr/lib/TheFolderIMeantToAlter'

and all folders leading up to it /usr

the [-] being the culprit (of course!!).
Got to watch these late night system alterations.

At some point sudo said NO.
And I,being a schmuck, jumped to su to force the issue.

All seems well, valuable lesson(s) learnt.
Seriously thought it was terminal, appreciate the wisdom people.

Many thanks,

Julian

On 10 June 2015 at 05:26, Mikael Flood the...@gmail.com wrote:

 Helllo Julian,

 Should just be to revert the change with 'chmod 755 /usr'.

 On 10 June 2015 at 05:40, Julian Brooks jbee...@gmail.com wrote:

 Hey all,

 Yes I'm an idiot...

 Not very experienced user here - 1st post:

 I mistakenly ran 'chmod -755 /usr'.

 How can I fix my permissions?

 Haven't rebooted yet, too scared. Currently getting around as root.

 Would prefer to avoid reinstall if possible.

 Cheers,

 Julian




 --
 //Yours sincerely Mikael Flood

Re: su chmod -755 /usr

[Cam Hutchison]

Julian Brooks jbee...@gmail.com writes:

Hey all,

Yes I'm an idiot...

Not very experienced user here - 1st post:

I mistakenly ran 'chmod -755 /usr'.

How can I fix my permissions?

Run 'chmod 755 /usr'.

All your command did was remove permissions from the /usr directory. Just
set them back the default. No need to reboot.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/48fc.5577ba04.18...@xdna.net

Re: su chmod -755 /usr

[Mikael Flood]

Helllo Julian,

Should just be to revert the change with 'chmod 755 /usr'.

On 10 June 2015 at 05:40, Julian Brooks jbee...@gmail.com wrote:

 Hey all,

 Yes I'm an idiot...

 Not very experienced user here - 1st post:

 I mistakenly ran 'chmod -755 /usr'.

 How can I fix my permissions?

 Haven't rebooted yet, too scared. Currently getting around as root.

 Would prefer to avoid reinstall if possible.

 Cheers,

 Julian




-- 
//Yours sincerely Mikael Flood

Re: su - root

[Andrei POPESCU]

On Ma, 03 sep 13, 03:09:46, Zenaan Harkness wrote:
 Can anyone explain to me the message here Added user root.:
 
 $ su - root
 Password:
 Added user root.
 ~#

Doesn't happen here.
 
 Did not happen with sudo su -. What does it mean??

BTW, you don't need 'su -' with sudo, just use -i.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: su user -c

[Guido Martínez]

On Thu, Jun 6, 2013 at 9:22 AM, Pol Hallen de...@fuckaround.org wrote:
 Hi all :-)

 this is the part of my script:

 email0=us...@domain0.org;email1=us...@domain1.org;name=user0;username=user1;domainname=domain0;echo
 | mutt -s test message $name -b email0 email1

 if I run this script of own user, runs correctly

 but when (inside the script) I use:

 su user -c
 email0=us...@domain0.org;email1=us...@domain1.org;name=user0;username=user1;domainname=domain0;echo
 | mutt -s test message $name -b email0 email1

You need to quote the command. su reads just 1 argument after -c and
invokes the sh -c command. Example:

guido@solid:~$ su someoneelse -c touch asd
Password:
touch: missing file operand
Try `touch --help' for more information.
guido@solid:~$ su someoneelse -c touch asd
Password:
touch: cannot touch `asd': Permission denied

Guido


 its does not run

 any idea?

 is it a problem with '  charset?

 thanks!

 Pol


 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/51b07ee9.8020...@fuckaround.org



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca++dqumsagvce68redxqpwbmmyarbbgam1z+zmnu_jv+t2n...@mail.gmail.com

Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable

[Sven Uhlig]

On 17.03.2013 02:53, Clive Standbridge wrote:
 The reasons seems to be my setup of the system.
 Debian runs in a VirtualBox environment, headless and w/o X server.
 I use ssh to connect to the system. (putty)
 I use X forwarding to run X applications on the system.
 The variable $DISPLAY gets set to 10.0.2.2:0 after ssh auth.
 
 I'm pretty sure that the value of DISPLAY means you are using a
 traditional X connection, and not actually using the X forwarding over
 ssh. ssh would set DISPLAY to localhost:10 or similar.

That is so true!
I have no idea why I have overlooked that fact.

 You will need to remove any setting of DISPLAY from your shell's
 startup files.

Done.

I guess at some point I wanted to be smart and expected that using a
direct connection was quicker than X11Forwarding.

mea culpa

 Make sure your /etc/ssh/sshd_config contains a line:
   X11Forwarding yes

$ grep X11 /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10

 Then connect from Putty without X forwarding. DISPLAY should not be
 set on the Debian machine.

$ echo $DISPLAY|wc --words
0

 Then connect from Putty with X forwarding. DISPLAY should be
 localhost:10 or similar.

$ echo $DISPLAY
localhost:10.0

 I hope this helps.

It actually does. Even if I keep X forwarding enabled and $DISPLAY set,
su is a lot faster now, good enough for me - problem solved.

Thank you very much for your help! :)

I think the reason why it is faster is that $DISPLAY is localhost with
dbus running. There is no Timeout in strace but only seemingly
successfull calls to the FD of the dbus socket.

Also if I do /etc/init.d/dbus stop su is even faster (read instant.)
And interestingly virt-manager still works without dbus. (virt-manager
is the package that also installed dbus)

Sven.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5145988d.2050...@web.de

Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable

[Sven Uhlig]

On 17.03.2013 03:12, Bob Proulx wrote:
 Sven Uhlig wrote:
 Bob Proulx wrote:
 The problem is that su takes 25 seconds before it
 succeeds.
 
 That sounds like a DNS timeout. If you do a dns lookup of your 
 systems hostname does it respond?
 
 # nslookup baldur ** server can't find baldur: NXDOMAIN
 
 # nslookup baldur.asgard ** server can't find baldur.asgard:
 NXDOMAIN
 
 Unfortunately nslookup only looks at DNS.  It is a DNS tool and
 does not follow /etc/nsswitch.conf for looking at other locations
 such as the /etc/hosts file.  It is the reason I use the libc tool
 'getent' to use the libc lookup routine and do whatever is
 configured.
 
 getent baldur.asgard
 

That is why I used C's getnameinfo().

How should getent work?

# getent baldur.asgard
Unknown database: baldur.asgard

# getent -V
getent (Debian EGLIBC 2.13-38) 2.13

Nevermind, my problem is solved, see mail by Clive Standbridge. :)

 # ping baldur PING baldur.asgard (127.0.1.1) 56(84) bytes of
 data.
 
 See that ping does do the lookup and does find the address okay.
 But although I know that many people use ping for a lookup tool
 that is really only a side effect of the primary purpose of ping.

I know but it is very convenient.

 That long delay in sudo with dns broken is why I suspected a 
 problem with your 'su' delay and was thinking it might be similar.

It is a network thing. $DISPLAY was set to 10.0.2.2:0 where it should
have been localhost:10.0

 In the output of strace I can see that /something/ happens with 
 libnss, so DNS lookup.
 
 Another brainstorm idea.  Do you have libnss-mdns installed?  As
 an experiment try removing it.  I doubt you are using it.  You can
 always install it again.

# apt-get purge libnss-mdns
Package 'libnss-mdns' is not installed, so not removed

 I wish I could be more help.  Hopefully someone knowledgeable
 about dbus will have help with a solution for it.

Well, no help regarding dbus. But regarding X11Forwarding.

Thank you for your input!

Sven.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514598ab.7020...@web.de

Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable

[Bob Proulx]

Sven Uhlig wrote:
 Bob Proulx wrote:
  getent baldur.asgard

 That is why I used C's getnameinfo().
 
 How should getent work?
 
 # getent baldur.asgard
 Unknown database: baldur.asgard

Sorry.  That was a bad example on my part.  The first parameter is the
map name and the second is the key to look up in it.

  getent hosts baldur.asgard

Other uses are for looking up passwd, group, aliases, and so forth.
Here are some additional examples of usage.

  $ getent aliases root
  root:   b...@proulx.com

  $ getent passwd rwp
  rwp:x:1000:1000:Bob Proulx:/home/bob:/bin/bash

  $ getent group staff
  staff:x:50:rwp

  $ getent hosts www.example.com
  2001:500:88:200::10 www.example.com

IPv6.  I guess I should have specified one of these:

  $ getent ahosts www.example.com
  192.0.43.10 STREAM www.example.com
  192.0.43.10 DGRAM  
  192.0.43.10 RAW
  2001:500:88:200::10 STREAM 
  2001:500:88:200::10 DGRAM  
  2001:500:88:200::10 RAW

  $ getent ahostsv4 www.example.com
  192.0.43.10 STREAM 43-10.any.icann.org
  192.0.43.10 DGRAM  
  192.0.43.10 RAW

  $ getent ahostsv6 www.example.com
  2001:500:88:200::10 STREAM www.example.com
  2001:500:88:200::10 DGRAM  
  2001:500:88:200::10 RAW

For just normal use I prefer the bind9-host command version of host
for the most friendly lookup format.

  $ host www.example.com
  www.example.com has address 192.0.43.10
  www.example.com has IPv6 address 2001:500:88:200::10

  $ host -t a www.example.com
  www.example.com has address 192.0.43.10

 Nevermind, my problem is solved, see mail by Clive Standbridge. :)

Yay!

Bob


signature.asc
Description: Digital signature

Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable

[Sven Uhlig]

On 16.03.2013 05:45, Bob Proulx wrote:
 The problem is that su takes 25 seconds before it succeeds.
 
 That sounds like a DNS timeout. If you do a dns lookup of your
 systems hostname does it respond?

# nslookup localhost
Name:   localhost
Address: 127.0.0.1

# nslookup 127.0.0.1
1.0.0.127.in-addr.arpa  name = localhost.

# nslookup baldur
** server can't find baldur: NXDOMAIN

# nslookup baldur.asgard
** server can't find baldur.asgard: NXDOMAIN

# ping baldur
PING baldur.asgard (127.0.1.1) 56(84) bytes of data.

 Look in /etc/hosts and look for (at least) these lines:

# grep 127. /etc/hosts
127.0.0.1   localhost
127.0.1.1   baldur.asgard   baldur

 Because PAM often logs the hostname to the system log and does
 other such DNS lookups.

Can I disable reverse DNS lookup?

 Using strace I think I identified the problem:
 connect(4, {sa_family=AF_FILE,
 path=/var/run/dbus/system_bus_socket}, 33) = 0
 ... poll([{fd=4, events=POLLIN}], 1, 25000) = 0 (Timeout)
 25.028989
 
 I can skip the timeout if I do either of these two things: 
 Solution 1) run X server on 10.0.2.2 (Xming) Solution 2) unset
 $DISPLAY
 
 If you dns lookup 10.0.2.2 does it resolve?  Quickly or after a
 longer timeout?

# nslookup 10.0.2.2
** server can't find 2.2.0.10.in-addr.arpa.: NXDOMAIN

# ping 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.

# ping wotan
ping: unknown host wotan

C's getnameinfo() returns: Name or service not known


But as it is a private IP, why should there be a DNS? Wouldnt everyone
have the same problem if they dont set up their own BIND or hosts file?

I have added the remote hostname to /etc:
# grep wotan /etc/hosts
10.0.2.2 wotan.asgard wotan

Of course I only get the following changes:
# ping wotan
PING wotan.asgard (10.0.2.2) 56(84) bytes of data.

C's getnameinfo() returns: wotan.asgard


Though no change in the behaviour of su, still a 25 seconds timeout
before it succeeds.

In the output of strace I can see that /something/ happens with
libnss, so DNS lookup. But unfortunately I am unable to tell what it
is. But there seems not to be any timeout related to DNS.

Any use of posting a full strace log? I dont think so.

 Hopefully someone else will have a better suggestion.

Thank you anyways. Getting any response is always good, instead of
being ignored completely :)

Sven.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/514422ec.90...@web.de

Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable

[Bob Proulx]

Sven Uhlig wrote:
 Bob Proulx wrote:
  The problem is that su takes 25 seconds before it succeeds.
  
  That sounds like a DNS timeout. If you do a dns lookup of your
  systems hostname does it respond?
 
 # nslookup localhost
 Name:   localhost
 Address: 127.0.0.1
 
 # nslookup 127.0.0.1
 1.0.0.127.in-addr.arpa  name = localhost.

Good.

 # nslookup baldur
 ** server can't find baldur: NXDOMAIN
 
 # nslookup baldur.asgard
 ** server can't find baldur.asgard: NXDOMAIN

Unfortunately nslookup only looks at DNS.  It is a DNS tool and does
not follow /etc/nsswitch.conf for looking at other locations such as
the /etc/hosts file.  It is the reason I use the libc tool 'getent' to
use the libc lookup routine and do whatever is configured.

  getent baldur.asgard

 # ping baldur
 PING baldur.asgard (127.0.1.1) 56(84) bytes of data.

See that ping does do the lookup and does find the address okay.  But
although I know that many people use ping for a lookup tool that is
really only a side effect of the primary purpose of ping.

  Look in /etc/hosts and look for (at least) these lines:
 
 # grep 127. /etc/hosts
 127.0.0.1   localhost
 127.0.1.1   baldur.asgard   baldur

Looks good.

  Because PAM often logs the hostname to the system log and does
  other such DNS lookups.
 
 Can I disable reverse DNS lookup?

The data you provided, that ping showed the lookup okay, says that
this isn't the problem.  The problem must be something else.  Which at
least is good to know by itself.  But it means you need to keep looking.

  I can skip the timeout if I do either of these two things: 
  Solution 1) run X server on 10.0.2.2 (Xming) Solution 2) unset
  $DISPLAY
  
  If you dns lookup 10.0.2.2 does it resolve?  Quickly or after a
  longer timeout?
 
 # nslookup 10.0.2.2
 ** server can't find 2.2.0.10.in-addr.arpa.: NXDOMAIN

 # ping wotan
 ping: unknown host wotan

At this point I would suggest that you try an experiment and add an
entry for 10.0.2.2 in your /etc/hosts file.  Does that cause this to
speed up?  But I see that you are ahead of me and did that experiment
already and it did not speed things up.

 But as it is a private IP, why should there be a DNS? Wouldnt everyone
 have the same problem if they dont set up their own BIND or hosts file?

Yes.  But most people don't use ssh and terminals these days and those
that do know to have their dns set up correctly.

This is actually a common problem with 'sudo' unless !fqdn is
specified in the options.  When dns is broken then sudo takes a very
long time when fqdn is specified.  Therefore I always turn that
off.  That long delay in sudo with dns broken is why I suspected a
problem with your 'su' delay and was thinking it might be similar.

 I have added the remote hostname to /etc:
 # grep wotan /etc/hosts
 10.0.2.2 wotan.asgard wotan
 
 Of course I only get the following changes:
 # ping wotan
 PING wotan.asgard (10.0.2.2) 56(84) bytes of data.

 Though no change in the behaviour of su, still a 25 seconds timeout
 before it succeeds.

It was a good experiment.  I wish it had solved the problem.

 In the output of strace I can see that /something/ happens with
 libnss, so DNS lookup. But unfortunately I am unable to tell what it
 is. But there seems not to be any timeout related to DNS.

Another brainstorm idea.  Do you have libnss-mdns installed?  As an
experiment try removing it.  I doubt you are using it.  You can always
install it again.

  apt-get purge libnss-mdns

I will cross my fingers and hope for good luck.

 Any use of posting a full strace log? I dont think so.

Doubtful.  Unless someone in the know about dbus asks for it.  You
have isolated it to a dbus problem.

  Hopefully someone else will have a better suggestion.
 
 Thank you anyways. Getting any response is always good, instead of
 being ignored completely :)

I wish I could be more help.  Hopefully someone knowledgeable about
dbus will have help with a solution for it.

Bob


signature.asc
Description: Digital signature

Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable

[Clive Standbridge]

 The reasons seems to be my setup of the system.
 Debian runs in a VirtualBox environment, headless and w/o X server.
 I use ssh to connect to the system. (putty)
 I use X forwarding to run X applications on the system.
 The variable $DISPLAY gets set to 10.0.2.2:0 after ssh auth.

Sven,

I'm pretty sure that the value of DISPLAY means you are using a
traditional X connection, and not actually using the X forwarding over
ssh. ssh would set DISPLAY to localhost:10 or similar.

Setting up ssh forwarding correctly could avoid your problem because
it will set DISPLAY only when it's valid.

You will need to remove any setting of DISPLAY from your shell's
startup files. Assuming you use bash, that would include
  /etc/profile
  /etc/bash.bashrc
  ~/.profile
  ~/.bash_profile
  ~/.bash_login
  ~/.bashrc
and anything sourced by those files.

Make sure your /etc/ssh/sshd_config contains a line:
  X11Forwarding yes
If it's missing, add it then restart the ssh server.

Then connect from Putty without X forwarding. DISPLAY should not be
set on the Debian machine.

Then connect from Putty with X forwarding. DISPLAY should be
localhost:10 or similar.

I hope this helps.

-- 
Cheers,
Clive


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130317015308.GA32005@rimmer.localdomain

Re: su - timeout for dbus/system_bus_socket if $DISPLAY set but unreachable

[Bob Proulx]

Sven Uhlig wrote:
 this is my first message to this list.

Welcome.

 I noticed a little problem on my system after I installed the package
 virt-manager and its dependencies on my system. One of the
 dependencies is dbus.

Ugh.  dbus.  I feel your pain.  Too many applications have egregious
dependencies upon dbus.  (For example I disagree that emacs needs dbus
to operate.  But there it is.)

 The problem is that su takes 25 seconds before it succeeds.

That sounds like a DNS timeout.  Although you have reported that it is
only when used with $DISPLAY set I still would want to double check
that the system's hostname is set up correctly.  If you do a dns
lookup of your systems hostname does it respond?

Look in /etc/hosts and look for (at least) these lines:

  127.0.0.1 localhost
  127.0.1.1 foo.example.com foo

Replace foo.example.com with your actual hostname.  That should be
there.  If that is not there then it is likely the source of dns
lookup timeout problems.  Because PAM often logs the hostname to the
system log and does other such DNS lookups.

 Using strace I think I identified the problem:
  connect(4, {sa_family=AF_FILE,
 path=/var/run/dbus/system_bus_socket}, 33) = 0
  ...
  poll([{fd=4, events=POLLIN}], 1, 25000) = 0 (Timeout) 25.028989

 The reasons seems to be my setup of the system.
 Debian runs in a VirtualBox environment, headless and w/o X server.

That sounds normal to me.  I would even go so far as to say
mainstream.  I would not call headless without X server unusual at
all.  And that it is VirtualBox shouldn't make any difference at all.
Most of us use ssh to connect.  And the X forwarding or not as we desire.
All of that is very normal.

 I can skip the timeout if I do either of these two things:
 Solution 1) run X server on 10.0.2.2 (Xming)
 Solution 2) unset $DISPLAY

If you dns lookup 10.0.2.2 does it resolve?  Quickly or after a longer
timeout?

Hopefully someone else will have a better suggestion.

Bob


signature.asc
Description: Digital signature

Re: su -c ne passe pas

[tv.deb...@googlemail.com]

On 03/11/2012 15:41, Bernard Schoenacker wrote:

bonjour,

j'essaye d'employer : su -c dpkg -i DraftSight.deb et ça ne
passe pas ...

qu'est ce que j'ai mal fait ?

slt
bernard



Peut-être

su -c dpkg -i DraftSight.deb

?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50953539.3060...@googlemail.com

Re: su -c ne passe pas

[list-debian]

Le 03/11/2012 15:41, Bernard Schoenacker a écrit :

bonjour,

j'essaye d'employer : su -c dpkg -i DraftSight.deb et ça ne
passe pas ...

qu'est ce que j'ai mal fait ?

slt
bernard



Bonjours,

il manque les quotes -

su -c 'dpkg -i DraftSight.deb'

--
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50953d96.3080...@gwilhom.fr

Re: su -c ne passe pas

[Bernard Schoenacker]

Le Sat, 03 Nov 2012 16:16:09 +0100,
tv.deb...@googlemail.com tv.deb...@googlemail.com a écrit :

 su -c dpkg -i DraftSight.deb

bonjour,

merci pour les doubles quotes, malheureusement le soft ne
fonctionne pas encore correctement

slt
bernard

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121103165240.23e5ff82.bernard.schoenac...@free.fr

Re: su -c ne passe pas

[list-debian]

Le 03/11/2012 16:51, list-deb...@gwilhom.fr a écrit :

Le 03/11/2012 15:41, Bernard Schoenacker a écrit :

bonjour,

j'essaye d'employer : su -c dpkg -i DraftSight.deb et ça ne
passe pas ...

qu'est ce que j'ai mal fait ?

slt
bernard



Bonjours,

il manque les quotes -

su -c 'dpkg -i DraftSight.deb'



Rho, il faut que j' apprenne à lire moi la réponse a déjà été donnée :)

Sinon quel sont la/les erreur(s) du soft ?

--
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50953eb1.5040...@gwilhom.fr

Re: su -c ne passe pas

[Bernard Schoenacker]

Le Sat, 03 Nov 2012 16:56:33 +0100,
list-deb...@gwilhom.fr a écrit :

 Le 03/11/2012 16:51, list-deb...@gwilhom.fr a écrit :
  Le 03/11/2012 15:41, Bernard Schoenacker a écrit :
  bonjour,
 
  j'essaye d'employer : su -c dpkg -i DraftSight.deb et ça ne
  passe pas ...
 
  qu'est ce que j'ai mal fait ?
 
  slt
  bernard
 
 
  Bonjours,
 
  il manque les quotes -
 
  su -c 'dpkg -i DraftSight.deb'
 
 
 Rho, il faut que j' apprenne à lire moi la réponse a déjà été
 donnée :)
 
 Sinon quel sont la/les erreur(s) du soft ?
 
bonjour,

il viande lamentablement au boot et nécessite de mettre sendmail
à la place de exim ...

slt
bernard

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121103201940.718be2be.bernard.schoenac...@free.fr

Re: su without a password (not root)

[William Hopkins]

On 05/27/11 at 05:28pm, Stanisław Findeisen wrote:
 On 2011-05-26 22:11, William Hopkins wrote:
  On 05/26/11 at 07:31pm, Stanisław Findeisen wrote:
  pam_wheel lets you su to root without typing a password if you are a
  member of a specific group.
 
  I need a PAM module with more flexible applicant user / target user
  pairs management. For instance I'd like to be able to su with no
  password from user A to users B and C, but not to root.
 
  What is the way to do it?
  
  If you must use PAM, consider a usage of pam_listfile and an authorized 
  list of target users, or setting sense=deny and blacklisting root 
  specifically. Configuring multiple pam modules to work together may be 
  necessary to meet every part of your requirement, and this can be 
  complicated and invites serious study and testing prior to implementation.
 
 Hm, in pam_listfile man page I can't see any way to restrict *target*
 user set...
 
Unfortunately I can't find it in the manpage either. Perhaps I was being 
forgetful, I could have sworn you could stack it so pam_listfile was usable in 
this scenario.
Perhaps just user pam_wheel deny group='somegroup', and add all the users you 
want to be able to su (but not to root) to 'somegroup'. Then they can su to 
their heart's content, but not to root. Of course, if they could figure out a 
user who wasn't in 'somegroup', they might su to that user and then to root. So 
perhaps you should ensure all users are a member of 'somegroup' (i.e. use the 
users group).

Or use sudo, which is designed for ACL-type management. (:


-- 
Liam


signature.asc
Description: Digital signature

Re: su without a password (not root)

[Stanisław Findeisen]

On 2011-05-26 22:11, William Hopkins wrote:
 On 05/26/11 at 07:31pm, Stanisław Findeisen wrote:
 pam_wheel lets you su to root without typing a password if you are a
 member of a specific group.

 I need a PAM module with more flexible applicant user / target user
 pairs management. For instance I'd like to be able to su with no
 password from user A to users B and C, but not to root.

 What is the way to do it?
 
 If you must use PAM, consider a usage of pam_listfile and an authorized list 
 of target users, or setting sense=deny and blacklisting root specifically. 
 Configuring multiple pam modules to work together may be necessary to meet 
 every part of your requirement, and this can be complicated and invites 
 serious study and testing prior to implementation.

Hm, in pam_listfile man page I can't see any way to restrict *target*
user set...

-- 
Eisenbits - proven software solutions: http://www.eisenbits.com/
OpenPGP: E3D9 C030 88F5 D254 434C  6683 17DD 22A0 8A3B 5CC0



signature.asc
Description: OpenPGP digital signature

Re: su without a password (not root)

[Jimmy Wu]

How about using sudo + sudoers instead?

2011/5/26 Stanisław Findeisen s...@eisenbits.com:
 pam_wheel lets you su to root without typing a password if you are a
 member of a specific group.

 I need a PAM module with more flexible applicant user / target user
 pairs management. For instance I'd like to be able to su with no
 password from user A to users B and C, but not to root.

 What is the way to do it?

 Thanks!

 --
 Eisenbits - proven software solutions: http://www.eisenbits.com/
 OpenPGP: E3D9 C030 88F5 D254 434C  6683 17DD 22A0 8A3B 5CC0


 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/4dde8e85.3040...@eisenbits.com




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimcob2m9jdr4xps-7rbrephzto...@mail.gmail.com

Re: su without a password (not root)

[William Hopkins]

On 05/26/11 at 07:31pm, Stanisław Findeisen wrote:
 pam_wheel lets you su to root without typing a password if you are a
 member of a specific group.
 
 I need a PAM module with more flexible applicant user / target user
 pairs management. For instance I'd like to be able to su with no
 password from user A to users B and C, but not to root.
 
 What is the way to do it?

If you must use PAM, consider a usage of pam_listfile and an authorized list of 
target users, or setting sense=deny and blacklisting root specifically. 
Configuring multiple pam modules to work together may be necessary to meet 
every part of your requirement, and this can be complicated and invites serious 
study and testing prior to implementation.

If PAM is not an absolute requirement, simply consider allowing the specific su 
commands via sudo. The sudo configuration is a much more straightforward access 
control and can be easily configured not to require passwords.

A basic sudoers example is listed:

User_AliasSU_USERS = username1,username2,username3 #users who may use 
su-to-user
Cmnd_AliasSU_NOT_ROOT = /usr/bin/su - targetuser1, /usr/bin/su - targetuser2

SU_USERS  ALL = NOPASSWD: SU_NOT_ROOT

now username1, 2 and 3 can sudo su - targetuser1 or sudo su - targetuser2 
without password, and attempts to su - or sudo su - will fail and be logged. 

Hope this helps!

--
Liam


signature.asc
Description: Digital signature

Re: su stopped working (after upgrade to squeeze)

[Hanspeter Kunz]

On Wed, 2010-10-27 at 14:48 +0200, Hanspeter Kunz wrote:
 On Tue, 2010-10-26 at 17:45 +, Camaleón wrote:
  On Tue, 26 Oct 2010 14:44:08 +0200, Hanspeter Kunz wrote:
  
   I have a strange problem on one of my debian squeeze boxes. when I try
   to become root (or any other local user), su fails with
   
 su: Authentication failure
   
   and no, the password is correct :)
  
  (...)
  
   My best guess is, that the problem is with my pam-configuration, but I
   have a lenny box with exactly the same pam-config that runs without
   problems.
   
   So any hints where to start looking are greatly appreciated.
  
  A very (very) wild guess... do you have installed libpam-ldapd? It 
  seems to be available for Squeeze/Sid but not for Lenny so maybe now that 
  you updated the system it could be a requirement to fulfill for ldap 
  logins :-?
 
 no I do not have pam-ldapd installed (I use pam-ldap). But thanks for
 the idea. I will investigate further.
 
 But any other ideas are still welcome.

just for the record, I finally tracked down the problem:

I had the line

auth optional  pam_smbpass.so migrate

in /etc/pam.d/common-auth.

Removing this line solves the problem. As I do not need password
migration anymore, this is fine for me. I will file a bug report.

cheers,
Hp


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1288255928.8057.4.ca...@franz.ifi.uzh.ch

Re: su stopped working (after upgrade to squeeze)

[Hanspeter Kunz]

On Tue, 2010-10-26 at 17:45 +, Camaleón wrote:
 On Tue, 26 Oct 2010 14:44:08 +0200, Hanspeter Kunz wrote:
 
  I have a strange problem on one of my debian squeeze boxes. when I try
  to become root (or any other local user), su fails with
  
  su: Authentication failure
  
  and no, the password is correct :)
 
 (...)
 
  My best guess is, that the problem is with my pam-configuration, but I
  have a lenny box with exactly the same pam-config that runs without
  problems.
  
  So any hints where to start looking are greatly appreciated.
 
 A very (very) wild guess... do you have installed libpam-ldapd? It 
 seems to be available for Squeeze/Sid but not for Lenny so maybe now that 
 you updated the system it could be a requirement to fulfill for ldap 
 logins :-?

no I do not have pam-ldapd installed (I use pam-ldap). But thanks for
the idea. I will investigate further.

But any other ideas are still welcome.

cheers,
Hp


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1288183683.4405.38.ca...@franz.ifi.uzh.ch

Re: su stopped working (after upgrade to squeeze)

[Camaleón]

On Tue, 26 Oct 2010 14:44:08 +0200, Hanspeter Kunz wrote:

 I have a strange problem on one of my debian squeeze boxes. when I try
 to become root (or any other local user), su fails with
 
   su: Authentication failure
 
 and no, the password is correct :)

(...)

 My best guess is, that the problem is with my pam-configuration, but I
 have a lenny box with exactly the same pam-config that runs without
 problems.
 
 So any hints where to start looking are greatly appreciated.

A very (very) wild guess... do you have installed libpam-ldapd? It 
seems to be available for Squeeze/Sid but not for Lenny so maybe now that 
you updated the system it could be a requirement to fulfill for ldap 
logins :-?

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2010.10.26.17.45...@gmail.com

Re: su?

[hugo vanwoerkom]

David Jardine wrote:

On Sat, Sep 11, 2010 at 04:36:48PM -0400, Doug wrote:

Tried to run a program from command line needing admin
capability.

Input su /usr/sbin/synaptic

Get message Unknown id: /usr/sbin/synaptic

Logged in as root, put in password, ran
/usr/sbin/synaptic

and the file ran fine.

Is there no su in Debian?  If not what replaces it?

Now I need some kind of prefix to put in the icon properties
so that symantic will run in admin mode, otherwise it can't
download anything.

Thanx,  doug


man su

But that's not what you want.  Use sudo (more reading :()




That wouldn't be so bad if it was reading from a manual. But you are 
reading from this funny screen that is hanging some distance in front of 
you. So you zero in on that backlit panel while your back is killing you 
all the while being grateful to technology for putting you into such a 
numbing position...
















--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/i6lbh4$9v...@dough.gmane.org

Re: su?

[Lisi]

On Monday 13 September 2010 15:12:48 hugo vanwoerkom wrote:
  But you are
 reading from this funny screen that is hanging some distance in front of
 you. So you zero in on that backlit panel while your back is killing you
 all the while being grateful to technology for putting you into such a
 numbing position...

Is there a good reason why you cannot move one or more of:  the screen, the 
chair, yourself, the desk?

Lisi 
(reading a screen around 15 or 20 cm away, slouching a bit so that the screen 
is dead in front.)  
Raising the screen would, of course, be a much better idea, but harder to 
acieve. :-(  


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201009131532.09749.lisi.re...@gmail.com

Re: su?

[Hilco Wijbenga]

On 11 September 2010 13:36, Doug dmcgarr...@optonline.net wrote:
 Is there no su in Debian?  If not what replaces it?

Yes there is. There's also 'man'. :-) Try 'man su' and you'll see you
need -c if you want to run a command. Maybe you are confused with
'sudo'?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTinCKRDGu;wcsnfi3gr_mcj1a_p227v2e_6...@mail.gmail.com

Re: su?

[Mihira Fernando]

 On 09/12/2010 02:06 AM, Doug wrote:

Tried to run a program from command line needing admin
capability.

Input su /usr/sbin/synaptic

Get message Unknown id: /usr/sbin/synaptic

Logged in as root, put in password, ran
/usr/sbin/synaptic

and the file ran fine.

Is there no su in Debian?  If not what replaces it?

Now I need some kind of prefix to put in the icon properties
so that symantic will run in admin mode, otherwise it can't
download anything.

Thanx,  doug

I think you've missed the -c parameter.
Try :
su  -c  /usr/sbin/synaptic


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c8beac4.8090...@gmail.com

Re: su?

[David Jardine]

On Sat, Sep 11, 2010 at 04:36:48PM -0400, Doug wrote:
 Tried to run a program from command line needing admin
 capability.
 
 Input su /usr/sbin/synaptic
 
 Get message Unknown id: /usr/sbin/synaptic
 
 Logged in as root, put in password, ran
 /usr/sbin/synaptic
 
 and the file ran fine.
 
 Is there no su in Debian?  If not what replaces it?
 
 Now I need some kind of prefix to put in the icon properties
 so that symantic will run in admin mode, otherwise it can't
 download anything.
 
 Thanx,  doug

man su

But that's not what you want.  Use sudo (more reading :()


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100911204815.ga2...@gennes.augarten

Re: su?

[Chris Jackson]

Doug wrote:


Tried to run a program from command line needing admin
capability.

Input su /usr/sbin/synaptic

Get message Unknown id: /usr/sbin/synaptic

Logged in as root, put in password, ran
/usr/sbin/synaptic

and the file ran fine.

Is there no su in Debian?  If not what replaces it?


/bin/su is in the login package.

If you want to supply a command to it, rather than run a shell, you need

su -c command

su something tries to change to user something and run a shell (man 
su for details).


--
Chris Jackson
Shadowcat Systems Ltd.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4c8beb08.9060...@shadowcat.co.uk

Re: su and environment.

[Sthu Deus]

Thank You for Your time and answer, Bob:

  $ su -c 'abc' -l anotheruser
  
  but it returns
  
  -su: abc: command not found
  
  The abc is in the anotheruser's path, but it seems option '-l' does
  not work here.
  
  How I can accomplish the goal (without manually specifying complete
  path)?
  
 The above command line worked for me.  What system are you using,
 which shell?

I do believe You - recently I had another strange experience and again
w/ bash's 'if' construction like this:

if [ $a == --help ]

- in one Debian 5 it worked, another - not!

I use Debian 5 mixture of stable and testing - all updated up-to-day.

Both users use

/bin/bash

version 3.2-4.
 
 Is this other user's path really getting set?  Is 'abc' executable and

No. And here the question arises, Why? As I do understand the su
manual. it says that option '-l' helps to load his (another_user's ENV).

 is the content runable (in other words, if it's a script and it begins
 with '#!/bin/bash', is bash really in /bin, or if it's binary, is the
 binary runable for the system you're on)?

Yes, it is executable - it runs just fine if I do:

su - another_user

and then in its shell run the

abc

w/o specifying the path and the abc is not in CWD.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c382a9b.ce7c0e0a.180f.4...@mx.google.com

Re: su and environment.

[Bob Proulx]

Sthu Deus wrote:
 $ su -c 'abc' -l anotheruser
 -su: abc: command not found
 
 The abc is in the anotheruser's path, but it seems option '-l' does not
 work here.

A very confusing topic and one often discussed is the process bash
uses to start up and what environment files are processed and at what
times.  PATH is usually set in a user's .profile (or .bash_profile).
The .bashrc is not loaded at login time and is usually sourced from
the .profile.

If a user has added PATH to .bashrc and hasn't sourced the .bashrc in
the .profile then something like the above can occur.  But that isn't
a correct configuration IMNHO.

Try this to print the PATH:

  su -l anotheruser -c 'printenv PATH'

 How I can accomplish the goal (without manually specifying complete
 path)?

Put PATH setup in the .profile (or .bash_profile) and source the
.bashrc from the .profile.

If modifying the other user environment is not possible then you would
need to source the files expliclitly.

  su anotheruser -c '. ~/.bashrc ; printenv PATH'

Bob


signature.asc
Description: Digital signature

Re: su and environment.

[Bob McGowan]

On 07/08/2010 02:27 AM, Sthu Deus wrote:
 Good day.
 
 The following:
 
 $ su -c 'abc' -l anotheruser
 
 but it returns
 
 -su: abc: command not found
 
 The abc is in the anotheruser's path, but it seems option '-l' does not
 work here.
 
 How I can accomplish the goal (without manually specifying complete
 path)?
 
 
 Thank You for Your time.

The above command line worked for me.  What system are you using, which
shell?

Is this other user's path really getting set?  Is 'abc' executable and
is the content runable (in other words, if it's a script and it begins
with '#!/bin/bash', is bash really in /bin, or if it's binary, is the
binary runable for the system you're on)?

You might want to try using the 'echo' or 'env' commands to validate the
environment variables PATH and HOME.  You may also want to try running a
normal system command such as 'date', to see if that works.

Good luck.

-- 
Bob McGowan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c366356.6080...@symantec.com

Re: su et applications graphiques

[steve]

apt-get install sux

puis

sux autreuser


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100414102217.gb13...@localdomain

Re: su et applications graphiques

[maderios]

steve a écrit :

apt-get install sux

puis

sux autreuser


Hyper simple. Merci.
Un détail gênant: Konqueror et Digikam démarrent mais ne fonctionnent pas
'Impossible de démarrer le processus Impossible de dialoguer avec 
KLauncher : Not connected to D-Bus server.'


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4bc59e72.8040...@gmail.com

Re: su et applications graphiques

[maderios]

steve a écrit :

apt-get install sux

puis

sux autreuser

Hyper simple. Merci.
Un détail gênant: Konqueror et Digikam démarrent mais ne fonctionnent pas
'Impossible de démarrer le processus Impossible de dialoguer avec 
KLauncher : Not connected to D-Bus server.'


La solution :
dbus-launch application

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4bc5a207.7050...@gmail.com

Re: su et applications graphiques

[FR]

Le mercredi 14 avril 2010 12:52:34, maderios a écrit :
 steve a écrit :
  apt-get install sux
  
  puis
  
  sux autreuser
 
 Hyper simple. Merci.
 Un détail gênant: Konqueror et Digikam démarrent mais ne fonctionnent pas
 'Impossible de démarrer le processus Impossible de dialoguer avec
 KLauncher : Not connected to D-Bus server.'

ssh -Xl [autreuser] localhost [appli]

-- 
FR

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201004141552.17910.deb...@miradou.com

Re: su depuis gnome ?

[François Cerbelle]

Alfred Sawaya a écrit :
fontionne mais ca m'ouvre un xterm pendant 1 seconde... Comment faire 
pour que l'opération soit transparente ? Pour ne pas utiliser le 
terminal ?  Sachant que je ne veux pas que l'utilisateur rentre de mot 
de passe au su (l'authentification se passe par bluetooth pour su.)



Peut etre que tu trouveras une solution du cote de gksu/gksudo. 
Attention, la configuration se fait dans gconf-editor (apps/gksu) pour 
choisir le mode de fonctionnement.


Fanfan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: su depuis gnome ?

[Guillaume MESSONNIER]

Bonjour,

Tu peux utiliser *gksudo*, l'utilisateur devra alors entrer son propre 
mot de passe pour exécuter la commande. Si tu souhaites qu'aucun mot de 
passe ne soit nécessaire, alors configure correctement *sudo* via le 
fichier */etc/sudoers*.
Pour cela, utilises la commande visudo. Je te renvoi à *man sudoers* 
pour retrouver la syntaxe...


Bonne après-midi,

Guillaume MESSONNIER

Alfred Sawaya a écrit :

Bonjour !

Je suis entrain de faire un script bash quoi doit être lancé par un 
lanceur sous gnome.
Dans ce script, je souhaiterais killer un processus... J'ai donc mis 
un su root -c kill $PID, jusque la tout va bien mais si je 
l'execute depuis mon lanceur, ca ne fonctionne pas. En effet depuis le 
lanceur gnome, je dois mettre xterm -e su root -c 'kill $PID' pour 
que ca fontionne mais ca m'ouvre un xterm pendant 1 seconde... Comment 
faire pour que l'opération soit transparente ? Pour ne pas utiliser le 
terminal ?  Sachant que je ne veux pas que l'utilisateur rentre de mot 
de passe au su (l'authentification se passe par bluetooth pour su.)


Merci !

Re: su depuis gnome ?

[Alfred Sawaya]

gksu marche nickel, merci beaucoup à tous :)


Guillaume MESSONNIER a écrit :

Bonjour,

Tu peux utiliser *gksudo*, l'utilisateur devra alors entrer son propre 
mot de passe pour exécuter la commande. Si tu souhaites qu'aucun mot 
de passe ne soit nécessaire, alors configure correctement *sudo* via 
le fichier */etc/sudoers*.
Pour cela, utilises la commande visudo. Je te renvoi à *man sudoers* 
pour retrouver la syntaxe...


Bonne après-midi,

Guillaume MESSONNIER

Alfred Sawaya a écrit :

Bonjour !

Je suis entrain de faire un script bash quoi doit être lancé par un 
lanceur sous gnome.
Dans ce script, je souhaiterais killer un processus... J'ai donc mis 
un su root -c kill $PID, jusque la tout va bien mais si je 
l'execute depuis mon lanceur, ca ne fonctionne pas. En effet depuis 
le lanceur gnome, je dois mettre xterm -e su root -c 'kill $PID' 
pour que ca fontionne mais ca m'ouvre un xterm pendant 1 seconde... 
Comment faire pour que l'opération soit transparente ? Pour ne pas 
utiliser le terminal ?  Sachant que je ne veux pas que l'utilisateur 
rentre de mot de passe au su (l'authentification se passe par 
bluetooth pour su.)


Merci !




--


-- 
|

   .:: Alfred Sawaya ::.
   |
 --

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: su depuis gnome ?

[Guillaume]

Le vendredi 13 février 2009, à 16:57:12, Alfred a écrit :

 Mon problème n'est pas de killer un logiciel ouvert sous gnome, je dois
 killer un processus qui n'a pas d'interface graphique. Je le lance dans
 mon script en faisant /usr/bin/monprocess.sh 
En automatisant le kill ?

-- 
Garanti 0% Micro$oft,
Envoyé sous Debian
--
Pourquoi payer des logiciels inutiles en achetant un ordinateur neuf ?
http://www.racketiciel.info

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Su carta!

[Eloi Notario]

El Dimecres 08 Octubre 2008 09:43:03 Pere Nubiola Radigales va escriure:
 Eloi:
  Lo que hi ha que fer es marcar-ho com a correu brosa a la llista.

Oops, pensava que estava a una altra llista on tenim costum de ficar-nos amb 
el correu spam :-P

-- 
Atentament,

Eloi Notario.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Su carta!

[Eloi Notario]

El Dimarts 07 Octubre 2008 00:34:56 J. G. va escriure:
 Bueno el dia!
 Necesitamos personas para realizar trabajo a distancia con nuestroz
 clientes.
 Estamos disPuestos a paGar 1350 (euros) por semana.
 El tiempo de trabajo es de 7 horaz diarias.
 El trabajo consiste en comunicarse por telefono e email con nuestros
 clientes.
 Si le parece interesante, pongaze en contacto con nuestro manager via
 email: [EMAIL PROTECTED]
 Indique en sucarta sunombre, edad y número telefónico.

No esTamoz inteResadoz, graCiaz.

-- 
Atentament,

Eloi Notario.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Su carta!

[Pere Nubiola Radigales]

Eloi:
 Lo que hi ha que fer es marcar-ho com a correu brosa a la llista.


2008/10/8 Eloi Notario [EMAIL PROTECTED]:
 El Dimarts 07 Octubre 2008 00:34:56 J. G. va escriure:
 Bueno el dia!
 Necesitamos personas para realizar trabajo a distancia con nuestroz
 clientes.
 Estamos disPuestos a paGar 1350 (euros) por semana.
 El tiempo de trabajo es de 7 horaz diarias.
 El trabajo consiste en comunicarse por telefono e email con nuestros
 clientes.
 Si le parece interesante, pongaze en contacto con nuestro manager via
 email: [EMAIL PROTECTED]
 Indique en sucarta sunombre, edad y número telefónico.

 No esTamoz inteResadoz, graCiaz.

 --
 Atentament,

 Eloi Notario.


 --
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]





-- 
Pere Nubiola Radigales
Telf: +34 656316974
e-mail: [EMAIL PROTECTED]
   [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

[OT] Re: Su mensaje era portador de virus

[Santiago José López Borrazás]

El 08/09/2008 11:36, Salvador Garcia Z. escribió:
 Por que se habren los correos de la lista, en un maldito windows?, por
 lo menos eso hay que hacerlo en un sistema operativo de verdad. Hoy
 resulta que tengo que poner un antivirus por que mi debian sera
 infectado por el W32/[EMAIL PROTECTED]
 Por favor hay que tomar esto con mas seriedad y decidan salir de bajo
 del ropero de una vez.
 Gracias.

¿?:

Received:
from virtualias.net (18.Red-88-21-161.staticIP.rima-tde.net [88.21.161.18])
by mail10.cdmon.com (Postfix) with ESMTP id A34CE104315 for
[EMAIL PROTECTED]; Mon, 8 Sep 2008 10:07:32 +0200 (CEST)

Alguien de esta IP tiene el virus este que se menciona, que es el
'W32/[EMAIL PROTECTED]'...

Lo que la gente aún ni tiene conocimiento de poner las últimas
actualizaciones para no infectarse de ese modo...

(que me entere yo...que hay cosas que la gente no sabe ni lo que es un virus...)

-- 
Slds. de Santiago José López Borrazás.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [OT] Re: Su mensaje era portador de virus

[Salvador Garcia Z.]

Santiago José López Borrazás escribió:

El 08/09/2008 11:36, Salvador Garcia Z. escribió:
  

Por que se habren los correos de la lista, en un maldito windows?, por
lo menos eso hay que hacerlo en un sistema operativo de verdad. Hoy
resulta que tengo que poner un antivirus por que mi debian sera
infectado por el W32/[EMAIL PROTECTED]
Por favor hay que tomar esto con mas seriedad y decidan salir de bajo
del ropero de una vez.
Gracias.



¿?:

Received:
from virtualias.net (18.Red-88-21-161.staticIP.rima-tde.net [88.21.161.18])
by mail10.cdmon.com (Postfix) with ESMTP id A34CE104315 for
[EMAIL PROTECTED]; Mon, 8 Sep 2008 10:07:32 +0200 (CEST)

Alguien de esta IP tiene el virus este que se menciona, que es el
'W32/[EMAIL PROTECTED]'...

Lo que la gente aún ni tiene conocimiento de poner las últimas
actualizaciones para no infectarse de ese modo...

(que me entere yo...que hay cosas que la gente no sabe ni lo que es un virus...)

  

Adrià.
Ya habéis mirado, mi comentario fue un absurdo. Solo me interesaba la 
reacción, no mas. Gracias por completar mi encuesta.

No os molestéis, pues si usas windows, no hay problema. Eres linda.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

OT: Re: Su mensaje era portador de virus

[Adrià]

2008/9/8 Salvador Garcia Z. [EMAIL PROTECTED]:
 [EMAIL PROTECTED] escribió:

 ATENCIÓN!

 Se ha detectado virus en su mensaje.
 El virus ha sido eliminado del mensaje y no será entregado.
 Para su seguridad le recomendamos que emplee un antivirus actualizado
 en su sistema informático.
 Los datos del mensaje son:
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Emisor:   debian-user-spanish@lists.debian.org
 Destinatario: [EMAIL PROTECTED]
 -----
 msg-80565-2.html  Infectado: HTML/IFrame
 message.scr   Infectado: W32/[EMAIL PROTECTED]
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


 

 Asunto:
 Mail Delivery (failure [EMAIL PROTECTED])
 De:
 debian-user-spanish@lists.debian.org
 Fecha:
 Mon, 8 Sep 2008 10:08:57 +0200
 Para:
 [EMAIL PROTECTED]

 Para:
 [EMAIL PROTECTED]


 Por que se habren los correos de la lista, en un maldito windows?, por lo
 menos eso hay que hacerlo en un sistema operativo de verdad. Hoy resulta que
 tengo que poner un antivirus por que mi debian sera infectado por el
 W32/[EMAIL PROTECTED]
 Por favor hay que tomar esto con mas seriedad y decidan salir de bajo del
 ropero de una vez.
 Gracias.

Los correos se abren, no se habren, para empezar. Ésta es de las fáciles.

Comentar tambien, que si se utiliza otro sistema operativo para leer
una lista de Debian es totalmente legítimo, ya sea porque no estás
delante de tu ordenador, GNU/Linux no te arranca por el motivo que
sea, quieres aprender y antes de has subscrito a la lista, etc...

Windows, nos guste o no, es un sistema operativo de verdad. Que tú y
yo usemos otro no significa que debamos desprestigiarlo (eso ya lo
hacen desde Redmond, así que en este sentido no hace falta que gastes
tus energías ;-) y EMHO deberías respetar la opción de cada uno.

Finalmente, decir que muchos virus/spammers utilizan direcciones
obtenidas o por internet o por otros medios como falsas direcciones de
remitentes (para dificultar la detección por parte de los sistemas
antispam): es por este motivo que los avisos y notificaciones que
emiten los antispam muchas veces llegan a un destinatario distinto al
que envió el correo. Mucho me temo que esto es lo que ha pasado.

Nada más.

Saludos,



 --
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact
 [EMAIL PROTECTED]





-- 
Adrià
[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Su mensaje era portador de virus

[Salvador Garcia Z.]

[EMAIL PROTECTED] escribió:

ATENCIÓN!

Se ha detectado virus en su mensaje.
El virus ha sido eliminado del mensaje y no será entregado.
Para su seguridad le recomendamos que emplee un antivirus actualizado
en su sistema informático.
Los datos del mensaje son:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Emisor:   debian-user-spanish@lists.debian.org
Destinatario: [EMAIL PROTECTED]
-----
msg-80565-2.html  Infectado: HTML/IFrame
message.scr   Infectado: W32/[EMAIL PROTECTED]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  




Asunto:
Mail Delivery (failure [EMAIL PROTECTED])
De:
debian-user-spanish@lists.debian.org
Fecha:
Mon, 8 Sep 2008 10:08:57 +0200
Para:
[EMAIL PROTECTED]

Para:
[EMAIL PROTECTED]


Por que se habren los correos de la lista, en un maldito windows?, por 
lo menos eso hay que hacerlo en un sistema operativo de verdad. Hoy 
resulta que tengo que poner un antivirus por que mi debian sera 
infectado por el W32/[EMAIL PROTECTED]
Por favor hay que tomar esto con mas seriedad y decidan salir de bajo 
del ropero de una vez.

Gracias.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Su, aptitude et fichier de configuration

[Gilles Mocellin]

Le Saturday 19 April 2008 13:44:06 [EMAIL PROTECTED], vous avez 
écrit :
 Bonjour,

[...]

 Je me mets alors à utiliser aptitude en ligne de commande :
   su
   aptitude install un_paquet
 et là je suis pratiquement sûr que /root/.aptitude/config n'est pas utilisé
 car les changements que je lui apporte manuellement sont ignorés. Par
 contre si je crée manuellement le fichier ~/.aptitude/config, visiblement
 celui-là est utilisé.

 Pouvez-vous me confirmer que cela est bien normal ? Je suppose que c'est
 lié au fonctionnement de su mais je n'en suis pas sûr. Une explication me
 serait utile mais je n'en trouve pas dans mes recherches.

Normalement, su garde l'environnement (variables, dont HOME) de l'appelant.
Pour que l'environnement de root soit chargé, il faut utiliser su -.

PS:
Moi, j'utilise sudo plutôt que su quand je dois lancer des commandes en etant 
root.


signature.asc
Description: This is a digitally signed message part.

Re: Su, aptitude et fichier de configuration

[verslenet-debian]

Gilles Mocellin wrote:

 Le Saturday 19 April 2008 13:44:06 [EMAIL PROTECTED], vous avez
 écrit :
 Bonjour,

 [...]
 
 Je me mets alors à utiliser aptitude en ligne de commande :
 su
 aptitude install un_paquet
 et là je suis pratiquement sûr que /root/.aptitude/config n'est pas
 utilisé car les changements que je lui apporte manuellement sont ignorés.
 Par contre si je crée manuellement le fichier ~/.aptitude/config,
 visiblement celui-là est utilisé.

Enfin, je n'en suis plus si sûr. Après avoir réessayé je suis de plus en plus 
confus.


 
 Normalement, su garde l'environnement (variables, dont HOME) de
 l'appelant. Pour que l'environnement de root soit chargé, il faut utiliser
 su -.

Vraiment ?
su
echo $HOME
me donne
/root

 
 PS:
 Moi, j'utilise sudo plutôt que su quand je dois lancer des commandes en
 etant root.

C'est aussi mon habitude une fois le système installé et configuré mais en 
attendant d'avoir configuré mon sudoers j'utilise su.

Merci pour ta réponse.

-- 
Strange Fruit

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Su, aptitude et fichier de configuration

[Gilles Mocellin]

Le Saturday 19 April 2008 16:55:32 [EMAIL PROTECTED], vous avez 
écrit :
 Gilles Mocellin wrote:
  Le Saturday 19 April 2008 13:44:06 [EMAIL PROTECTED], vous avez
 
  écrit :
  Bonjour,
 
  [...]
 
  Je me mets alors à utiliser aptitude en ligne de commande :
  su
  aptitude install un_paquet
  et là je suis pratiquement sûr que /root/.aptitude/config n'est pas
  utilisé car les changements que je lui apporte manuellement sont
  ignorés. Par contre si je crée manuellement le fichier
  ~/.aptitude/config, visiblement celui-là est utilisé.

 Enfin, je n'en suis plus si sûr. Après avoir réessayé je suis de plus en
 plus confus.

  Normalement, su garde l'environnement (variables, dont HOME) de
  l'appelant. Pour que l'environnement de root soit chargé, il faut
  utiliser su -.

 Vraiment ?
   su
   echo $HOME
 me donne
   /root

Heu, alors là, je suis étonné. Ca me donne la même chose que toi ici...


Le man n'est pas suffisamment clair, (et pas complètement traduit !) :

DESCRIPTION
   The su command is used to become another user during a login session. 
Invoked without a username,
   su defaults to becoming the superuser. The optional argument - may be 
used to provide an
   environment similar to what the user would expect had the user logged 
in directly.

   Des paramètres supplémentaires peuvent être fournis après le nom de l
´utilisateur. Dans ce cas, ils
   sont donnés à l´interpréteur de commandes de connexion de l
´utilisateur. En particulier, le
   paramètre «\fB-c » considère que le paramètre suivant est une commande 
pour la plupart des
   interpréteurs de commandes. La commande sera exécutée par l
´interpréteur indiqué dans /etc/passwd
   pour l´utilisateur cible.

   Vous pouvez utiliser le paramètre -- pour séparer les options de su des 
paramètres fournis par
   l´interpréteur de commandes.

   Un mot de passe sera demandé à l´utilisateur, si nécessaire. Les mots 
de passe incorrects
   produisent un message d´erreur. Toutes les tentatives, réussies ou non, 
sont enregistrées afin de
   détecter tout abus du système.

   The current environment is passed to the new shell. The value of $PATH 
is reset to /bin:/usr/bin
   for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser. 
This may be changed with the
   ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.

   Une connexion à un sous-système est indiquée par la présence d´un « * » 
comme premier caractère de
   l´interpréteur de commandes initial. Le répertoire personnel sera 
utilisé comme racine d´un nouveau
   système de fichiers dans lequel l´utilisateur sera connecté.


signature.asc
Description: This is a digitally signed message part.

Re: su doesn't work Authentication failure

[Kevin Buhr]

Dennis G. Wicks [EMAIL PROTECTED] writes:

 Kevin Buhr wrote the following on 01/31/2008 12:50 PM:

 From aptitude show login ==  1:4.0.18.1-7  ==
 should give:
 
  1381ae1ac77b512258657b096522bb6a  /bin/su
c80fc747e24fa8bfa099cbef0bfb926f  /bin/su ==
 from md5sum /bin/su

 If your Etch version matches mine but the md5 doesn't, you might start
 to get pretty worried.

Dennis, I posted a followup message but you might have missed it.  I
was sloppy: the 1381... hash I posted was for the amd64 architecture;
the c80f... hash you list matches what should be expected for i386, so
there's no problem with your copy of /bin/su.

 What should I be worried about and start looking for?

Since yours *does* match, you don't have any worries.

More generally, though, in the normal course of events, files (other
than configuration files and the like) installed on your system should
match the version in the appropriate Debian package.  A hash mismatch
just means the files don't match.  There are many possible
explanations for this, most of them innocent:

1.  First, as we encountered above, the package version, architecture,
or official source of the package might not match precisely.

When I say official source, the main Debian archive and any of
its mirrors would be considered a single source, so all should
have precisely matching packages.  On the other hand, if you
install packages you've compiled from source or gotten from a
backports site or from a derivative distribution (Ubuntu, etc.),
a mismatch is likely occur even with a perfect
version/architecture match.

2.  The file might be a special file that gets modified on
installation.  Configuration files in /etc for example will
frequently differ from the source, even when a package is freshly
installed.

3.  The file might have been intentionally modified by the system
administrator.

4.  The file might have become corrupted.

5.  The file might have been installed from original installation
media whose copy didn't precisely match the file in the official
package and no later version of the package has ever been
installed.

6.  The file might have been tampered with by someone who broke into
your system.

7.  You may have somehow been tricked into installing a malicious
version of the package.

These are probably in roughly the order of likelihood, so I should
have tried harder not to sound alarmist, since the ones to worry about
are way down at the bottom of the list.

For /bin/su, a mismatch is cause for immediate suspicion (especially
if, as seemed to be the case for the original poster, something weird
is going on with that file anyway) simply because it's a
security-sensitive utility that is a frequent target for rootkits and
the like.

-- 
Kevin Buhr [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: su doesn't work Authentication failure

[Damon L. Chesser]

paul wrote:

Hello,

on my debian etch machine 'su' doesn't work if a password is needed.
It is possible to do 'su someuser' from root but it's not possible to
get back to root then using just 'su' or change from a normal user to
another user account.


myserver:/tmp$ su
Password:
su: Authentication failure
Sorry.

auth.log says:
Jan 31 15:44:18 myserver su[27729]: (pam_unix) authentication failure;
logname= uid=1000 euid=1000 tty=pts/4 ruser=myuser rhost=  user=root
Jan 31 15:44:20 myserver su[27729]: pam_authenticate: Authentication
failure
Jan 31 15:44:20 myserver su[27729]: FAILED su for root by myuser
Jan 31 15:44:20 myserver su[27729]: - pts/4 myuser:root

I suspect sth. in with the pam module got broken.

Any suggestions how to go on?

thx, paul


  

Paul,

I had the same issue.  I fixed it by doing two things: 


1.  I used sudo to su to root sudo su
2.  As I had a BadCRC reported on a HD, I had to re-configure my 
hardware setup and re-install.


The first is a bandaide.  The 2nd is a shotgun to kill a bug.  Both 
worked.  The source was never found.


HTH

--
Damon L. Chesser
[EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: su doesn't work Authentication failure

[Kevin Buhr]

paul [EMAIL PROTECTED] writes:

 It is possible to do 'su someuser' from root but it's not possible to
 get back to root then using just 'su' or change from a normal user to
 another user account.

[ . . . ]

 Jan 31 15:44:18 myserver su[27729]: (pam_unix) authentication failure;
 logname= uid=1000 euid=1000 tty=pts/4 ruser=myuser rhost=  user=root

The euid=1000 should read euid=0: your su is running as the
invoking user, so it fails for non-root users.  The most likely
explanation is that /bin/su doesn't have the setuid flag set, so
that would be the first thing to check.  (If the setuid bit *is* set,
the problem may be that your root partition has been mounted with the
nosuid mount flag or something.)

If you have a logical explanation for the missing bit, great,
otherwise good security practice would suggest that you give a little
thought before restoring setuid bits on files where it has
mysteriously disappeared.  If your version of the login package is
the latest official Etch version 1:4.0.18.1-7, then md5sum /bin/su
should give:

 1381ae1ac77b512258657b096522bb6a  /bin/su

If your Etch version matches mine but the md5 doesn't, you might start
to get pretty worried.

-- 
Kevin Buhr [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: su doesn't work Authentication failure

[Kevin Buhr]

Kevin Buhr [EMAIL PROTECTED] writes:

 If your version of the login package is the latest official Etch
 version 1:4.0.18.1-7, then md5sum /bin/su should give:

  1381ae1ac77b512258657b096522bb6a  /bin/su

Sorry.  That was sloppy of me.  The above hash is for the amd64
architecture.  The md5sum for the i386 architecture should be:

   c80fc747e24fa8bfa099cbef0bfb926f  /bin/su

-- 
Kevin Buhr [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: su doesn't work Authentication failure

[Dennis G. Wicks]

Kevin Buhr wrote the following on 01/31/2008 12:50 PM:
 paul [EMAIL PROTECTED] writes:
 It is possible to do 'su someuser' from root but it's not possible to
 get back to root then using just 'su' or change from a normal user to
 another user account.
 
 [ . . . ]
 
 Jan 31 15:44:18 myserver su[27729]: (pam_unix) authentication failure;
 logname= uid=1000 euid=1000 tty=pts/4 ruser=myuser rhost=  user=root
 
 The euid=1000 should read euid=0: your su is running as the
 invoking user, so it fails for non-root users.  The most likely
 explanation is that /bin/su doesn't have the setuid flag set, so
 that would be the first thing to check.  (If the setuid bit *is* set,
 the problem may be that your root partition has been mounted with the
 nosuid mount flag or something.)
 
 If you have a logical explanation for the missing bit, great,
 otherwise good security practice would suggest that you give a little
 thought before restoring setuid bits on files where it has
 mysteriously disappeared.  If your version of the login package is
 the latest official Etch version 1:4.0.18.1-7, then md5sum /bin/su
From aptitude show login ==  1:4.0.18.1-7  ==
 should give:
 
  1381ae1ac77b512258657b096522bb6a  /bin/su
   c80fc747e24fa8bfa099cbef0bfb926f  /bin/su ==
from md5sum /bin/su

 If your Etch version matches mine but the md5 doesn't, you might start
 to get pretty worried.
 

What should I be worried about and start looking for?
BTW, nobody can get access to my system unless they
break into my house, and that hasn't happened. I even
did a reinstall of the login package just to make sure
the above was right!

Regards,
Dennis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: su doesn't work Authentication failure

[Chris Henry]

On Feb 1, 2008 1:10 PM, Dennis G. Wicks [EMAIL PROTECTED] wrote:
 What should I be worried about and start looking for?
 BTW, nobody can get access to my system unless they
 break into my house, and that hasn't happened. I even
 did a reinstall of the login package just to make sure
 the above was right!

If the md5 actually doesn't match, it could be that the file has been
damaged or somebody has managed to break into your computer and
replace `su` with another file. I think that's what he meant by really
worried. Even if it's your home computer, it doesn't mean that
malicious groups can't hack in and take control over your computer.
(In that case, your computer setup is probably not secure and you'd
want to look into it.)


Chris


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: su and administrator password fails in gnome

[Sven Joachim]

On 2008-01-03 05:07 +0100, Ron Johnson wrote:

 On my system, all the non-symlinks in /bin are 755 root:root.

Then your system is rather unusual, to say the least.  The following
programs are 1755 on my system:

/bin/su
/bin/mount
/bin/umount
/bin/ping
/bin/ping6

Not having /bin/su suid root is probably Rick's problem.

Sven


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]