Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote:
> On Jo, 10 dec 20, 13:34:55, Reco wrote:
> > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote:
> > > On Jo, 10 dec 20, 12:52:56, Reco wrote:
> > > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote:
> > > > >
> > > > > passwd -l/--lock <username>
> > > >
> > > > sudo -u <locked_user> /bin/bash -i
> > > >
> > > > That little trick defeats "locked" account status, an absence of a
> > > > password and even /usr/sbin/nologin set as a default shell.
> > >
> > > With sudo access one can also unlock the account as well, so how is this
> > > relevant?
> >
> > Of course it's relevant. The whole point of sudo is to be a controlled
> > privilege escalation mechanism.
> > I.e. you can grant an ordinary user A to execute a certain binaries with
> > certain arguments as a different ordinary user B, *and* you do not have
> > to provide an ordinary user A an access to root.
>
> At least on Debian sudo has to be explicitly configured to allow a
> regular user to use '-u' with another user name. We can only assume the
> admin had good reasons to that, possibly on purpose (see below).
You're correct here, one has to explicitly allow such activity in
sudoers in Debian and just about any OS I've encountered these years
(assuming it has sudo, of course).
I just like to remind you the original question:
Is there a way to put an account "beyond use", in any way including su,
sudo etc,
*In any way* includes the way I've described above IMO.
> > Also, passwd(1):
> >
> > -l, --lock
> > Note that this does not disable the account. The user may still
> > be able to login using another authentication token (e.g. an SSH key).
> > To disable the account, administrators should use usermod --expiredate 1
> > (this set the account's expire date to Jan 2, 1970). Users with a
> > locked password are not allowed to change their password.
>
> As I said, there are limitations, that may or may not be desired, e.g.
> I'm using the SSH access option, because 'systemctl --user' doesn't work
> via 'sudo -u' (and it's a remote system anyway).
It can, it's just inconveniencely (sp?) annoying.
I.e. you have to make sure that dbus-daemon is running as a target user
and you have to set DBUS_SESSION_ADDRESS to a right value, and about the
only way to get that right value is to look at
/proc/<insert_right_pid_here>/environ.
Whoever thought it's a good idea to couple systemctl and dbus deserves
something really bad happening to them.
Reco
Reply to: