[TAG] lpr works for user not root in Basiclinux 2.1

Sindi Keesan keesan at grex.cyberspace.org
Tue Feb 27 08:13:34 MSK 2007


On Mon, 26 Feb 2007, Ben Okopnik wrote:
>>
>> We had a long discussion about why it is bad to go online as root, which
>> is how Basiclinux is set up to operate.
>>
>> My current compromise is to:
>>
>> 1.  Dial as root (because dialing as user would give the user access to
>> the login name and password, which would then let anyone with access to
>> the user account know these, and besides if I try to dial as user pppd
>> complains about not having /etc/ppp/options, which root does not need).
>
> Just to correct a misconception on your part: the information in
> /etc/ppp/*-secrets does not have to be readable by the user; this is why
> '/usr/sbin/pppd' is set SUID 0. In fact, that's the default
> configuration on every Linux system I've seen, including the one I've
> just set up on my new laptop:

We don't HAVE a /usr/sbin/pppd.  We use eznet to dial with (it tells pppd 
what to do) and it uses /var/eznet/eznet.conf which contains login info.

When I try to dial as user, pppd wants /etc/ppp/options (which we also do 
not have).  When I dial as root that is not needed.

>
> ``
> ben at Tyr:~$ ls -l /usr/sbin/pppd /etc/ppp/*secrets
> -rw------- 1 root root     80 2006-05-30 20:58 /etc/ppp/chap-secrets
> -rw------- 1 root root   1628 2006-05-30 20:58 /etc/ppp/pap-secrets
> -rwsr-xr-- 1 root dip  306720 2006-07-05 06:22 /usr/sbin/pppd
> '''
>
> The above means that any user who is part of group 'dip' can execute
> 'pppd' - and since 'pppd' runs as root, it can read the files that
> contain the name and the password.

In my attempts to dial I ended up with pppd -rwsr-sr-x root root
I am experimenting ....
chgrp users pppd  chmod o-r pppd    chmod g-s pppd

Ten minutes later I have -rwsr-xr-- root users pppd

This linux came with one 'user' login who lives in /home/user and uses 
/bin/sh.  Root uses /bin/bash (according to /etc/passwd).  I had to make 
/home/user owned by user (chown -R user user chgrp -R users user) before I 
could save anything to it.  As I said, this is a single-user distribution.

I compiled a new busybox which has adduser and addgroup (my linux had 
neither).  I have used adduser once.

addgroup users tells me it is already in use.

Next problem is that we are dialing with eznet not directly with pppd.

My pap-secrets is also not world-readable and it contains the same login 
and password info as eznet.conf.  I don't know where eznet looks for 
info.

I think you are saying if I set pppd SUID, then the user can use pppd, 
which can read the login and password info from pap-secrets, but the user 
cannot do that directly, so it is safe.  But I don't know how to dial with 
pppd directly, just via eznet.

I will set eznet like pppd.

It is currently -rwsr-sr-x root root - probably should not be executable 
by user.  chgrp users eznet  chmod u+s eznet
Now -rwsr-xr-- root users

eznet.conf is -rw-------   readable by root like pap-secrets.

An attempt to dial as user STILL wants /etc/ppp/options.

(I hope I can still dial as root after all this.)


Does the following help any:

I can type 'eznet up 4' to get the fourth login and password etc. (set up 
to use the lucent modem) listed in eznet.conf.  ps lists as a process:

/usr/sbin/pppd /dev/ttyLT0 115200 connect /usr/bin/eznet chat 4 
defaultroute lock modem mtu 552 mru 5 (goes off the screen).

(LT0 is a lucent modem for which I somehow managed to compile the 
modules.  It does not keep disconnecting due to line noise like the 
external 1997 USR that I updated from X2 to v90. crw-r--r-- root root).

> In other words, it appears as though you're taking a mechanism that
> works just fine and changing it so that it will do the same thing as
> it's doing now. I suggest that understanding the current mechanism would
> serve you better than trying to construct something new from the ground
> up - especially since it's not new.

I don't have the standard setup to start with.

>> 3.  Put into /home/user/profile the line startx (rather than editing
>> inittab to make vt1 run X, which does not work any more anyway once you
>> add a user account).
>
> This means, of course, that you'll be trying to start X every time you
> log in. Perhaps making it conditional would work better.

This is only for other people who only want to use opera in linux.  I want 
to save them a step.  But this stopped working.

To use X as user I needed to make Xvesa and rxvt o+x (or it would complain 
about permissions) and also suid root (Xvesa told me so).

-rws--x--x root root Xvesa 
-rws--x--x root root rxvt

Then rxvt complained  about pseudo-ttys so I changed permissions:

crw-rw-rw- root tty   ttyp1 
crw--w--w- user users ttyp2
crw-rw-rw- root root  ttyp3 through 6

Should these all be readable by user or just writeable? 
Probably root tty for all.

It is much easier to just dial as root then proceed as user. Lynx and 
links worked perfectly.  I need to load Xvesa and rxvt as user to use
opera as user.

I had to change permissions to make /dev/null writeable by user for opera.
And chown -R user user to /home/user.

pppd and ssh  are still looking for files I don't even have.

>> Permission denied (publickey, password, keyboard-interactive).
>>
>> If I login user:
>>
>> ssh_askpass:  exec (/opt/diet/libexec/ssh_askpass):  No such file or
>> directory.
>> Write failed:  broken pipe
>>
>> (I don't even have an /opt).

> In that case, either recompiling 'ssh' to look for 'ssh_askpass' in a
> different place, or creating the above path and a link to the
> actual location of 'ssh_askpass' should help.

I don't know how to compile ssh.  Our distribution author did it 
(statically against uclibc).  A few of our users know how to compile and 
one of them is in TAG.  He will try to compile uclibc-static latest 
openssh, and maybe can explain how to use ssh as user in our distribution. 
We don't have a default config file for ssh either.

I don't have an ssh_askpass any more than I do /etc/ppp/options.  I don't 
even have an /opt - that is for some other distribution, I think.
It works for root without either of those.  Might this be related to user 
using /bin/sh and root using /bin/bash?  Root has a .bashrc which user 
may not be accessing but it only sets the prompt and a few aliases.
I am lost here.

Is ssh not secure enough to use as root?  I no longer telnet.

I just compiled putty's psftp and pscp for secure file transfers instead 
of kermit ftp or busybox ftpput and ftpget.

This reply took a couple of hours.  I am learning a lot.  Thanks.

Sindi Keesan

>
> -- 
> * Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *




More information about the TAG mailing list