On 14/03/2015 20:53, Matti Nykyri wrote: >> On Mar 14, 2015, at 12:47, German <gentger...@gmail.com> wrote: >> >> On Sat, 14 Mar 2015 10:33:59 +0000 >> Neil Bothwick <n...@digimed.co.uk> wrote: >> >>> On Sat, 14 Mar 2015 06:08:34 -0400, German wrote: >>> >>>>> Forget about "chmod 770". Better do a "chmod g+rw". :-) >>>> >>>> Tried it, it also doesn't stay permanently. OK, no solution :( >>> >>> The correct solution is a udev rule, but it appears that something may be >>> overriding that when you login. >> >> I have the same udev rule. Yes, something is overriding it. >> >> A kludgy solution is to add the chmod >>> command to ~/.bash_profile. > > Don't hit your head to a brick wall. A small strace to the login process > reveals that login set things as you tell it to in /etc/login.defs > > In this file change the line: > TTYPERM 0600 > To: > TTYPERM 0620 > > And your problem is fixed. > > The problem has nothing to do with udev. If you don't like a volatile /dev > just remove udev and create everything you wan't by hand (not recommended ;) > > Another thing i'm puzzled by is, why do you wan't to login as root and the su > to someone else? I usually do it the other way around... >
There is a use-case for doing it (but I highly doubt the OP is using it) Take a system user like eg sybase or rancid. You can't run those apps as root (it messes with permissions etc, and some scripts detect EUID 0 and refuse to run). The sybase and rancid users can't log in at all, and the system is set up so I can't su as me to that account directly. So I have to go from my login account to root then drop privs to the system user. -- Alan McKinnon alan.mckin...@gmail.com
