when i execute sudo syscheck ,
i get the following:
sudo: /etc/sudoers is world writable
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
tried resolving using bash pkexec: pkexec: command not found
not able to install policy kit , i get error as below:
debian@beaglebone:/etc$ apt-get install -y policykit-1-gnome.
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?
This appears to be your basic problem. The file /etc/sudoers says which users are allowed to use sudo to perform system activities. However, the file is “world writable,” which means that anyone could go in there and add themselves to the list. So sudo is not allowing anybody to do system administration.
If you can figure out a way to change the permissions on that file, you should be in an improved position. You might try booting from an SD card and changing the permission on the copy of /etc/sudoers that’s on the MMC, or if you’re already booting from an SD card, you might be able to put that card in a different Linux computer and change the permissions from there.
Can you post the output of “ls -l /etc”? That might help (especially the line for sudoers, but maybe there are widespread permission problems in /etc?)
You have a lot of permission problems in /etc…it looks like /etc/sudoers doesn’t have write permission set (despite the error message) but far too many of the other files and directories are 0777 (rwxrwxrwx). Perhaps /etc is also 0777, which I guess would be another reason for the error message.
Even if you’re able to fix the sudo problem, you’ll probably have other persistent trouble until you fix the rest of the permissions. Do you have any idea how this could have happened? (Were you adjusting permissions of some other file, and accidentally got all of /etc?)
If you don’t have a lot of customization and precious data on the system, the easiest thing would be to re-flash the OS and start over. I don’t know of a way to check and set permissions correctly over a whole system, other than maybe setting a fairly restrictive permission and then relaxing as problems come up.
i wanted to login to BBAI through SSH from windows 10 using ethernet.
i had created a static ip and was able to ping this ip in windows.
but in power shell when i did → ssh debian@ip.address , it said connection refused
so i changed default port from 22 to 2222 .
it didnt work
then i was changing firewalll settings in BB , thats when this happened.
Whoever ran `chmod -R 777 /etc` on your BeagleBoard… send them on a Unix
Administration 101 course and ban them from use of your hardware until
they pass the exams.
Permissions are set a particular way for a reason. This isn't MS-DOS.
However it's doubtful if one wants or needs serious security on a BBB
which will probably only ever have one user. OK, the normal/default
permissions will prevent you (as a user) doing things that only root
(which presumably will be you, on purpose) should be able to do, by
mistake, but that's about all.
You just need to remove lock-frontend file for unlocking the installation of new module
kindly try this line:
sudo rm /var/lib/dpkg/lock-frontend
If it does not succeed, got to /var/lib/dpkg directory, and try manually removing all lock files as it would stop the new installation of packages of libraries.
Hope it helps.
I would suspect this is of no help to the OP... They have a corrupted
file system and are unable to execute any "sudo" command, and hence will
not have privileges to remove any lock files.
Well, in some cases yes, you will be just running as a single user, you
might consider running everything you need as 'root', however this is
still not good practice and should not be encouraged.
I'd advise against doing so in any sort of production environment.
It's one of the overheads of a full-blown operating system, if you want
to skip the privilege separation, consider a RTOS.
Do a `ps ax | grep dpkg` to check nothing actually _is_ running before
doing that!
If it shows something other than `grep dpkg` as running at the time,
removing the lock file and running a second instance could make a mess
of your package database.
> However it's doubtful if one wants or needs serious security on a BBB
> which will probably only ever have one user. OK, the normal/default
> permissions will prevent you (as a user) doing things that only root
> (which presumably will be you, on purpose) should be able to do, by
> mistake, but that's about all.
Well, in some cases yes, you will be just running as a single user, you
might consider running everything you need as 'root', however this is
still not good practice and should not be encouraged.
No, I agree, I certainly don't do everything as root, as I said, apart
from anything else, it protects one to some extent from one's own
errors. That # prompt makes me check twice (or more!) before hitting
return. (I tend to do 'sudo -i' so I *do' get a # prompt).
I'd advise against doing so in any sort of production environment.
A home/domestic system is hardly a "production environment"!