[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: id gives conflicting results

>     Juha> These are different, why? According to man id "id" and "id
>     Juha> <currently logged on user>" are the same.
> The first one shows the groups that are assigned to the current
> process, the second one shows the default list of groups the user will
> get when logging in again.

Ach, I did not know this, but it is not the issue here since they were
both issued on a brand-new ssh session; i.e. they should have provided
the same list.

> That is normal for AFS. Normally I believe AFS only uses two groups
> though, something strange here.

Yep, which is why I doubt they can be the culprit here. Russ, however,
seems to think it's possible. Given the comment Aaron Ucko, I am inclined
to agree with Russ. This is not the whole story, however.

I have an X (started with gdm) session, where any shell will give me

~> id
uid=1000(juhaj) gid=1000(juhaj)

If I ssh from within this X session to the machine, I get *the exact same
list* - even in the same order this time! The plain shell cannot
access /var/log/syslog, but the shell over ssh can. The file is 644

A side note: on *this* machine, I *can* access the cdrom, but on the one
I originally pasted the id outputs, I could not. Go figure?

> I am not convinced it is a good idea to define the group both on the
> system and in LDAP. I prefer to keep low level system groups in
> /etc/group and high level user groups in LDAP.

This is exactly what I am after, but it does not seem to work. =(

> Try bypassing the AFS login stuff (if possible) and see if it changes
> anything.

That would be quite nasty since it would mean throwing away $HOME. If I
log in from a getty, I can access /var/log/syslog (or /dev/hdc)
regardless whether I obtain the AFS PAG or not. I can *only* reproduce
this problem on

a) machine A, user juhaj, file /var/log/syslog, X/gdm
b) machine B, user X, file /dev/hdc, X/gdm

I can work around these by

a) from within X ssh to localhost
b) log in from vt[1-6]

Both users belong to their "uid-group" both in LDAP and /etc/group, both
users also have a corresponding uid in /etc/{passwd,shadow}. These extra
groups are relics which I have not thought necessary to remove; accounts
in /etc/{passwd,shadow} exist because sudo won't work otherwise. (Our
users are accustomed to sudo, not "ssh root@localhost" with .k5login
allowing them to log in. Perhaps I could globally 'alias sudo="ssh
root@localhost"' and edit /root/.k5login accordingly on each machine?)

What should I try next? =)


                | Juha Jäykkä, juolja@utu.fi			|
		| Laboratory of Theoretical Physics		|
		| Department of Physics, University of Turku	|
                | home: http://www.utu.fi/~juolja/              |

Attachment: signature.asc
Description: PGP signature

Reply to: